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(57) Abstract 

A software/hardware system which provides immediate, on-going interaction between an institution and its customers. The system 
communicates with customers/subscribers over numerous, different communication channels and actively screens market conditions for 
situations that could potentially impact its customers, based on the customer's unique situation and prearranged instructions. The system 
and method interacts with the institution's processing centers which handle incoming customer transactions and the system creates outgoing 
messages. The system has a decision making component used to make the decision in each case as to which information to push to the 
customer in the form of a message. The message is delivered to the customer via any communication channels presently known. The system 
allows the customer to respond electronically or by telephone or by fax or by any means, all of which are intended to allow the institution 
to receive the response information from the customer expeditiously and to enable the institution to act upon the customer's instructions. 
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BACKGROUND OF THE INVENTION 

The present invention relates to banking 
10 services and more particularly to a system and method 

which provides virtually immediate, on-going interaction 
between a banking institution and its customers. 

Decades ago, financial institutions had the 
capability of offering service that could be tailored 
15 almost down to the single customer. For example: The 

Bank of Smalltown receives through deposit or clearing, a 
check on the account of valued customer Jones. The check 
will cause the customer's account to go into overdraft. 
The Bank reaches Jones by phone and advises him of the 
20 situation. Jones promises to come to the Bank that day 

with a cash deposit sufficient to cover the overdraft. 
At three o'clock, closing time for the Bank, Jones has 
not arrived. The branch manager, Smith, knows that Jones 
will honor his promise and assumes he must have been 
25 delayed. He also knows that Jones will suffer if the 

check is returned (i.e. returned to the bank of first 
deposit or to the local depositor - colloquially, the 
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check will bounce) . Smith keens 

, . ^mj-uxi Keeps Jones account open. 

Jones arrives at ion « « , 

*„ / P nd apologizes through the 

lcc*ed door to Smith, smith tai.es Jones , money through 
**e slot in the Band's door and records the deposit. 
Service on a personal level such as described above, is 
. largely a thing or the past. 

rec, • ! 0day '. cust ° ne « have three possible ways to 
receive information from their financial service 
institution. First, a customer can receive paper and/or 
microform records shipped to them on a prearranged 
schedule, second, the customer can subscribe J an 
online service that allows the customer to pull down 
information from online databases that are updated on a 
fixed schedule. In the case of a corporate customer 4e 
service is called, for example, an .online cash 

customr^T' W " le CaSe ° f a " ^vidual 

customer, the online system is usually called a -home 

banking system-. Typically, both of the above systems 

operate on intraday or intramonth batching schedu^ 

These systems interleave exceptional information wi^h 

everyday reporting, are cumbersome when there is , Lge 

amount of data, are labor intensive, and are prone to^ 

pre=L S i : n na b ; i t S ! ed °«™*«~ -less managed with close 

precision by the customer. in ^«,=^— ^ 

, , . _ xn essence, the customer cretc; 

accounts on an account ^ ^^T^Z^ 1 ' 

Tmm • / n0t relia *le since the 

recipient may not be n°»r +-»>i^' ~w 

y De near the phone and a message 

recording device may not be activated 

in." ReaS ° nS UnaVailab ^ity, expense or 

xnefrectxveness of such personal services include the 
volume of transactions passing through the financial 
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networks, the number of businesses and persons having one 
or more accounts, the inability to precisely pinpoint the 
exact time -when a service or special attention will be 
needed by a customer and finally, the inability to 
reliably communicate bi-directionally between the 
customers and the financial service institution at the 
point when knowledge of the information is critical. 
This last point is especially true in the case of retail 
customers, individuals, regarding the reliable delivery 
.of corifirmatibhs of receipt of instructions and 
confirmation of executed transactions. 

The present invention addresses the 
aforementioned drawbacks of the prior art in the form of 
a new system and service which establishes a new paradigm 
15 in the delivery of financial banking services. This new 

paradigm is referred to herein as "Push Banking". The 
terminology "Push Banking" is inspired, in part, by the 
evolution of the concept of "Push Technology" on the 
Internet. 

Push Technology, as implemented to date, is an 
attempt to address the growing problem of the enormous 
amount of available information on the Internet. 
Existing search engine technology is . inadequate to get 
reliable access to certain pieces of information. Such 
25 searches return thousands or tens of thousands of "hits" 

which must be searched with ever increasing ingenuity on 
the part of the operator. Even so, the final results of 
the automated search must usually be reviewed by the 
searcher to find the required information, if it can be 
30 found at all. "Push" in this context means that the 

information is sent to the operator by the system. 
-Pull" refers to the original search engine model where 
the operator requests the information from the system. 

It appears that in all cases of Push Technology 
there exists an implicit profile of the information the 
operator desires to receive (usually established by the 
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operator before the initiation of push services), in most 
cases there is an active application on the operator's 
workstation which -polls" a server on a periodic basis 
and downloads the information to the operator's terminal 
and displays it. in this case, it appears to the 
operator that the information is being "pushed" to him. 
More correctly, however, the operator has installed an 
application that does periodic customized searches (i.e. 
"pulls") and then displays the results of the search. In 
at least one case, a Push Technology (from a company 
. Backweb™) is used to do automatic software upgrades. 

The terms "Webcasting" and "Netcasting" are 

also sometimes used interchangeably with "Push." Indeed 
the radio or television broadcast is an archetype of the 
15 ; "Push" concept. In - Web /Netcas ting" there is usually 

some sense of a filtered or customized broadcast (e.g. as 
described by a company PointCast™ under the term 
Personalcast™) . This implies a large common pool of 
broadcast information which is limited or filtered in 
some way to suit an individual operator. However, none 
of the prior art implements or teaches a pure Push 
Banking process as contained in the present invention 
which is driven by data of essential concern to a 
customer and facilitates immediate response from the 
customer via two way acknowledgement interaction. 

■ SUMMARY OF THE INVENTION 

Accordingly, the present invention is a 
software/hardware system which provides increased 
diversity in. the delivery of banking services. The 
system provides virtually immediate, on-going interaction 
between a banking institution and its customers and 
delivers to banking customers the information the 
customers need, at the moment it is available, at the 
customer's convenience. 
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The present invention is software driven system 
which is capable of reaching customers/subscribers over 
numerous, different communication channels and actively 
screens market conditions for situations 1 that could 
5 potentially impact its customers, based on the customers' 

unique financial situation and prearranged instructions. 

The present invention overcomes the limitations 
of the prior art by providing a comprehensive, fast, 
reliable, less expensive notification process for banks 
10 or other institutions with which to communicate relevant 

information to clients via messages that represent the 
considered whole of all the information at the time of 
transmission. The information can include a information 
about a customer's accounts and personal information of 
high importance to clients in a reliable and timely 
manner. 

The drawbacks of the prior art have been 
ameliorated and the above and other objects of the 
invention have been realized in the form described below, 
20 by the instant inventors who have worked under the 

auspices of the assignee of the present invention, The 
Chase Manhattan Bank (••Chase") . 

As a financial services entity, any bank has 
access to certain customers' financial information sooner 
25 than the customers. Additionally, if customers had 

earlier access to some of their account information based 
on prearranged screening (e.g. performed by Artificial 
Intelligence (AI) or other process) of the customers' 
situations vis-a-vis some emerging situational 
information, the customers could take immediate action in 
order to correct adverse financial impacts or to 
otherwise take advantage of the information. The 
entirety of the invention does not rest with the earlier 
correction of financial issues, but rather relates to the 
35 timely provision of financial information to a customer 

which enables the customer to take the earlier action. 
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The services realized by the present invention 
range from on-demand payment services to presenting 
critical information on a timely basis. The present 
invention, referred to herein as Push Banking, is 
5 designed to automatically send information to the 

customer, with the means for the customer to make the 
appropriate response on which the Bank can then act. m 
contrast, in today's environment, a customer must 
affirmatively seek the information and then respond 
Id accordingly. For example, suppose a customer has 

exceeded the credit-line on his credit card and has the 

_ 1 funds in his . checking account to pay. off the- credit card . 

In the prior art system of notification to the customer, 
the customer's response to the bank to use funds from the 
15 checking account will typically, arrive too late. m ' ■ 

contrast, the Push Banking system of the present 
invention alerts the customer of the over-limit condition 
immediately and allows the customer to pay the credit 
card overdraft immediately from the checking account, or 
20 stop payment in the event of fraud. 

The present invention also provides substantial 
business processing benefits. Today, a bank's financial 
data must be processed twice, serially - once in order 
for it to be outputted by the Bank to the customer and 
again for it to be inputted, analyzed and acted upon by 
the customer. The Push Banking system of the present 
invention reduces the frequency and amount of manually 
initiated . double processing of information. This 
reduction in labor and inefficiency has also the 
unanticipated and beneficial effect of allowing the time 
— between the creation or receipt of a significant piece 
of information by the bank, its transmission to the 
customer and the receipt of any needed response from the 
customer — to collapse to the minimum time possible 
relative to communication technology and the customer's 
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ability to receive a transmission via at least one of 
many possible means. 

The present invention is a new paradigm in bank 
service. It represents a new offering that responds to 
the scarcest commodity of all — time. it anticipates 
the need for customers to react to information 
independent of time zones restrictions. This new paradigm 
changes the time dimension as well as the content 
dimension of the information delivered by any banking or 
financial institution to its customers. The present 
invention is not Push Technology and it is not simply 
using Push technology to deliver information. 

An integral part of the system and method of 
the invention that implements the aforementioned service 
is referred to herein as the Push Active Filter (PAF) . 
The Push Active Filter interacts with the bank's 
processing centers which handle incoming customer 
transactions and creates outgoing transactions. The Push 
Active Filter also interacts with various data banks 
containing customer account information, transaction 
histories, current transaction activity, and derived 
analytical/ statistical data as well as external sources 
cf information such as the Internet. 

The Push Active Filter employs artificial 
intelligence and other analytical tools as well as 
customer specific profiles to make the decision in each 
CJle as to which information to push to the customer. 
In formation is pushed automatically, on a virtually 
instantaneous basis, as soon as the information becomes 

-a liable so that customers may act on it relatively 
.Rso-iiately. 

The Push Active Filter is a software/hardware 
c = -.struct, that is responsible for selecting and conveying 
tr.« information to the customer, based on knowledge of 
t.-.<r type of tools that are available (or unavailable) at 
tr.e customers' site. This allows the invention to 
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delxver information to the customer via any communication 
means presently known,- or that might be available in the 
future. This includes telephone, telegraph, fax, beeper, 
one-way. cable TV, one-way satellite, . dial-out terminal, 
on-line terminal, Internet, Intranet or Extranet, 
SmartPhone, 2 -way beeper, 2-way cable TV, 2-way 
satellite, Personal Digital Assistant (PDA) , Personal 
computer (PC) , express mail delivery, commercial express 
delivery and various systems of the type mentioned above. 
These systems allow the customer to respond 
electronically or by telephone or by fax or by any means, 

a11 ° f Which are intended to allow the bank to receive 

the response information from the customer expeditiously 
and to enable the bank to act upon the customer's 
15 instructions . 

The Push. Active Filter consists of two main 
components: the Push Active Filter Decision Component 
(PAFDC) and the, Push Active Filter Communication 
component (PAFCC) . The PAFDC receives information input 
from all the accounts of every client subscribing to this 
service, since the number of clients can be very large 
(millions) , the invention provides ready partitioning 
across physical devices to enable practical 
implementation of a service, with immediate notification 
capability. The PAFDC contains notification criterion 
values supplied by each client for use with bank 
specified conditions to initiate notices to those 
clients. The PAFDC creates the notices when the specified 
conditions occur and sends those notices to a 
corresponding PAFCC for transmission by any channels 
known by the. PAFCC to be effective in reaching the 
client.. By. partitioning the clients into groups serviced 
by PAFDC-PAFCC pairs, scalability to large numbers of 
clients, is assured. Each PAFCC, upon receipt of 
communications from a client, relays the communication to 
its corresponding PAFDC and other systems if applicable. 
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Errors detected by the PAFCC are communicated to the 
PAPDC to cause proper corrective action. The PAFCC also 
corrects errors and takes corrective action. 

The PAFDC periodically runs through the list of 
5 clients that it contains and determines if any of the 

clients should be notified, if any responses from 
previous notifications have been received, and if any 
transactions initiated by the PAFDC have been completed. 
The PAFDC receives account information at a rate that 
10 depends on the method of implementation. Three methods 

of implementation are envisioned, to be used in any 
combination: 1) account information is sent to the PAFDC 
on a client whenever a change in the client's account 
occurs/ 2) the PAFDC requests data from an account 
15 database when needed, 3) agents of the PAFDC, possessing 

knowledge of the notification criterion values specified 
by the clients and located at the relevant data sources, 
send data on a client to the PAFDC only when a 
notification condition occurs. 
20 The PAFDC, upon determining that more than one 

message is to be sent or a message (s) is (are) to be sent 
and a prior message(s) has (have) been sent that is (are) 
still pending completion of the required action (s) , makes 
an overall determination of the most appropriate action 
25 to take. It may decide that the present condition 

warrants no new notification (s) because the prior 
notice(s) is (are) still valid and adequate. It may 
decide that a new message is required to modify past 
instructions and/or add a new instruction (s) . The 
3 0 preferred embodiment thus makes its determinations in two 

steps, first deciding on individual accounts, taking into 
consideration nuances specific to that type of account 
for that particular client in view of the client's stated 
preferences. Then, second, it collects all notices 
35 generated by the first step and decides what notice(s) 

should be sent, if any, in light of messages previously 
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sent, but whose intended activity has not been brought to 
conclusion, aS well as considering the possible 
interaction between newly generated first step notices 
(e.g. advising to transfer an amount to one account, and 
to transfer an amount to a second account, when the sum 
of the two transfers would overdraw the source account) . 

Once the PAFDC decides what message(s) has 
(have) to be sent to the client; it generates the 
message (s) with a unique message identifier (s) that 
enables tracking the message (s) through the system until 
they are brought to conclusion. The message(s) is (are) 
. . sent to the. .corresponding PAFCC for transmission to" the" 
client either as soon as they are prepared, or in groups, 
or at completion of the entire client list, as determined 
by the requirements of the system at the time of 
designing the system (although building a system that 
adapts to changing conditions is possible) . A unique 
client ID is also placed in each message to enable the 
PAFCC to determine who is to receive the message. The 
PAFCC contains the necessary information on each client 
to decxde how to transmit the message. 

A priority for the message is assigned by the 
PAFDC to guide the PAFCC in determining the order in 
which to send messages when limited by channel capacity 
The PAFDC time stamps each message with a Stale Date to" 
enable the client to determine whether a response could 
still be effective if sent. The PAFCC uses the stale Date 
to mitxate a clean up of messages not responded to 
within the allotted time. The PAFCC notifies the PAFDC 

with tt T CleanSd ^ 9 meSkagW by gating * response 
with that information content. Any response received 
after clean up is treated by the PAFDC in a manner 
sxmilar to when it receives a client initiated Message; 
it sends a message to the client informing the client 
that the response was received too late and no action 
taken. If at that time a new relevant notice is to be 
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sent to the, client, the two messages would be combined 
into one coherent message. Client initiated messages 
otherwise are reacted to by the PAFDC in a manner similar 
to receiving a response to a message sent to the client* 

In order for the client to control which 
communication channels are used to transmit the messages, 
the PAFCC maintains a list of channels and priorities 
that are settable by the client (e.g. the client may be 
going on a trip and wants to eliminate messages to his 
home and designate his mobile unit as the top priority 
receiver) . Because of the difference in message 
capacity, security and formatting across the range of 
devices, the PAFCC also maintains a list of device types 
and formats messages according to the actual capabilities 
15 of the target device (s). The PAFDC includes a numeric 

code with the message that designates a class of 
communication to the PAFCC that is associated with the 
account type to which the message pertains, making it 
simpler for the PAFCC to select the correct communication 
class. When the PAFDC wants to delete a prior message, 
such as when a superseding message must be sent prior to 
receiving a response to an earlier relevant message, a 
specific value of the numeric code informs the PAFCC to 
remove the prior message identified by the unique message 
25 identifier included in the message. 

When a response to a message is received by the 
PAFDC from a client (via the PAFCC) , it reads the 
response when it next gets to that client in its- 
processing cycle. The PAFDC is able to recognize what 
3 0 message is being responded to by the unique message 

identifier included in the response that has been copied 
from the message into the response by the responding 
mechanism (the . identifier copy is provided by the client 
if the client doesn't possess an automated response 
35 mechanism) . Client initiated messages have a unique code 

(e.g. zero) that enables recognizing it as client 
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initiated. If the identifier copy is corrupted, 
predetermined rules direct the PAFDC how to handle the 
situation; either accepting the response as genuine with 
a message to that effect to the client > or requesting 
5 confirmation. ; 

When a message has been responded to and the 
indicated transaction successfully completed or responded 
to, the PAFDC issues an acknowledgment that requires no 
response. However the PAFCC checks that the message is 
10 received and viewed. This information is kept in the 

PAFCC ' s history file for audit purposes. 

_ m 3^. a 9^ .^^..^9 PAFDC has sent _are„saved„ 

in two files. One file contains just active messages that 
have not been closed out. The other file archives all 
15 messages for future reference if needed to trace actions 

taken. The latter file can be used by customer service 
representatives while answering calls from clients, in 
order to see what activity has preceded the call. 

When the bank is made aware of any situation 
20 requiring notification in accord with agreements made 

with the bank, the PAFDC is informed and a coordinated 
message is sent- in a manner similar to the financially 
triggered messages described above. Thus the invention 
anticipates a broader service than traditionally handled 
25 by a bank in view of the comprehensive notification 

process, provided by the invention. In fact, the 
processing of the invention is of a general nature that 
will be recognized as being applicable beyond just the 
banking industry. In particular, the applicability of the 
30 processing to such well known activities as workflow 

processing or bill presentment will be seen as benefiting 
from this new functionality. 

When notification to a customer is required, it 
may require minimal time delay in sending the notice. In 
3 5 order to provide this immediacy of response economically, 

it may be necessary to interrupt the normal processing 
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cycle described above, which may encompass millions of 
accounts, to service one or more urgent messages. The 
preferred embodiment therefore provides this capability 
by completing the processing of any client it is 
5 processing, and then issuing the urgent message and all 

messages processed up to the time of receiving the urgent 
message. The urgent message is combined with any other 
messages already processed for that client. The process 
then continues processing the remaining clients in its 

10 normal order, including the client for whom the urgent 

message was sent if it had not been processed prior to 
receiving the interruption. 

Other features and advantages of the present 
invention will become apparent from the following 

15. description of the invention which refers to the 

accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a high level generalized block 
diagram of a typical, prior art banking processing 
20 environment; 

Figure 2 illustrates the location of the Push 
Active Filter of the present invention relative to the 
other components of the prior art typical banking system 
of Figure 1 ; 

25 Figure 3 is a high level block diagram of the 

overall system of the present invention; 

Figure 4A depicts the Push Active Filter of the 
present invention communicating through Push Channels to 
Push Docks of the invention in order to push information 
30 to a customer; 

Figure 4B is a block diagram showing the Push 
Active Filter of the present invention operating with the 
Push Dock and Push Channel in a customer response mode of 
the invention ; 
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Figure 5A is a high level block diagram of the 
Push Banking system of the present invention; 

p. h » * • ?lgUre 5B ±S 3 high 1SVel block diagram of the 
Push Active Filter of the present invention; 

Fxgure 6A depicts the architectural components 
of the Push Active Filter of the present invention; 

a * «, DS / i9Ure 63 dePiCtS ±n a0re detail the components 
of the PAF Decision Comppnent of the present invention; 

Figure 6C illustrates the architectural 
components of the PAFCC; 

■ t* • " . ./ igUre 7 lllustrates ^ block diagram format 
- the. architecture of the- ^us^bmer .components of the " " 
present invention; 

Figure 8 illustrates two types of. dock models; 
Fxgure 9A illustrates the information flow 
during a Push operation; 

Figure 9B illustrates the "clean-up" and "dock 
full message" operations; . 

Figure 10 illustrates the acknowledgment 
procedures of the present invention; 

(PAFCC) prlTfX 1 ^ 8 ^ PAF C — -™ 

Figure 12 shows the process for . capturing 
customer profiles; 

r 911 " 5 13A " 13D fl ° W dia ^ams lowing the 

processes for different procedures involving 

communications with the customers having different types 
of physical devices; * H 

Figures 14A-14H show various screens of devices 

::rr banking inst — - - - — , ces 
Vision c ^:; t ; 5 " 21 depictfiow di ™ ° f the - 

Figure 22 illustrates a Communications, 
Decision Making & Caching Component; 
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Figure 23 depicts a plurality of CMDCs and used 
in a network environment; 

Figure 24 illustrates the server side of an 
Internet Dock; 
5 Figure 25 shows the process flow for an 

Internet XML message being sent to a customer; 

Figure 26 shows the process flow for monitoring 
and deleting a Push message; 

Figure 27 illustrates a block diagram of a Dock 
10 employing an applet viewer (the Listener and Applet 

Viewer reside on the customer's device); 

Figure 28 illustrates the process of the Dock 
of Figure 27 for a Push message; 

Figure 29 illustrates the process of the Dock 
15 of Figure 27 for multiple Push messages with different 

priorities; 

Figure 3 0 shows the process of sending an 
Applet instead of an XML document to a Dock; 

Figure 31 illustrates the process of 
20 reprioritizing and cleaning up unprocessed messages; 

Figure 32 shows the process for a Customer 
initiated message; 

Figure 33 depicts the architectural components 
of a Server configuration for pager processing including 
25 the components at the Bank, the paging company and the 

pager ; and 

Figure 34 illustrates the flow for processing a 
pager message. 

DETAILED DESCRIPTION OF THE INVENTION 

30 Figure 1 is a high level generalized diagram of 

a typical current banking processing environment. This 
Figure depicts the prior art system 10 comprising a 
processing section 12 which is responsible for processing 
incoming transactions 14, e.g. money deposits, drafts, 

35 orders to pay bills, money transfers, letters of credit 
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and the like. Processed information is output by the 
processing section 12 as outgoing transactions 16, such 
as banking .statements, notification of various events and 
the like to banking customers. The bank processing 
5 section 12 makes use of information that is looked up or 

obtained from customers accounts 18 , transaction 
histories 20 and derived analytical and statistical data 
22. 

Although described throughout this discussion 
10 with respect to a banking system, the present invention 

is applicable to any industry, or person which must act on 
time sensitive information. , 

As shown in Figure 2, an integral component of 
the present invention comprises the Push Active Filter 
15 (PAF) 30 which the invention has incorporated into the 

prior art environment depicted in Figure 1. As shown, 
the Push Active Filter (PAF) 30 also interacts with other 
sources of information such as public and private 
information 32, information from other banks 34 not 
20 currently used in normal bank processing, and product 

specific agents 22a providing immediate messages,. 

The block diagram of Figure 3 is intended to 
convey the gist of the overall system of the present 
invention which comprises a new paradigm in banking 
25 pursuant to which the customer, does not look for banking 

information. Rather, the information looks for the 
customer. When the information arrives, it brings with 
it the means to make an appropriate response so that the 
customer gets the information the customer needs, as soon 
30 as the information is available, at the customer's 

convenience, with the ability to take immediate action on 
the information. 

To this end, as shown in Figure 3, the Push 
Active Filter 30 operates in conjunction Push Channels 
35 36a-36n. and Push Docks 38a-38n to enable the system of 

, the present invention to interact with customers and/ or 
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electronic devices associated with customers through 
communication media 40. The communication media 40 is 
intended to encompass any mode of communication between a 
banking institution and its customers that is capable of 
5 transmitting information to the customer either 

electronically or in hard copy or any other format. This 
includes, by way of example and not limitation: 
telephone, telegraph, fax, one-way beeper, one-way cable 
TV; one-way' satellite, dial-out terminal, on-line 
10 terminal, Internet, Intranet or Extranet, SmartPhone, 2- 

way beeper, 2 -way cable TV, 2 -way satellite, Personal 
Digital Assistant (PDA) , Personal Computer (PC) , express 
mail delivery, commercial express delivery and various 
systems of the type mentioned above. As will be described 
15 in greater detail further on, the function of the Push 

Active Filter 3 0 is to select and establish 
communication, and to carry out the transmission of 
information via the communication media 40 to the 
customers and from the customers back to the bank. The 
20 Push Docks 38a-3 8n are located at the customer's side of 

the system and represent the diverse nature of bank 
customers and their devices with which communication must 
be established. These include customers who wish to be 
reached via Personal Digital Assistant or Personal 
25 Computer or paper or fax or beeper or cable TV or 

SmartPhone, ' etc. 

The present invention applies equally to 
systems of the future where it might occur that all 
potential Docks are directly addressable via unique 
30 addresses on the Internet and all use standard Internet 

communication protocols or other communications standards 
or virtually any form of communications. 

The system of Figure 3 is designed such that 
the Push Active Filter 30 constantly monitors the results 
35 of bank transactions and information obtained from other 

databases to make decisions whether to "push" information 
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to various customers. Throughout this discussion, the 
term ..Push" will be used to describe the information or 
messages which is (are) sent (pushed) to a customer. The 
Push decisions are made,, as shall be explained in more 
5 detail further on, based on various predetermined 

information and customer profiles. The key is to get the 
information to ; the customer as rapidly as possible, 
without the customer asking for it. Moreover, the system 
of the present invention expects, in most cases, to 
10 receive an interactive, response from the customers to the 

information that has been presented. 

To. this end, .Figure 4A shows- the Push Active 

Filter (PAF) 30 acting on public information 32, bank 
information alerts 19a, and general^banking information 
15 19 (comprising the sources of information identified by 

reference numerals is, 20, 22 and/or 34 in Figures 2 and 
3). Push Active Filter 30 creates a Push 44 (a message 
or applet) and thereafter chooses the appropriate/optimal 
channel or channels from among the Push Channels 36a, 
36b... 36n with which to communicate with the customer (s) 
The PAF 30 thereafter packages the information in the 
appropriate format (s) and transmits that information over 
the chosen channel (s) 36a-36n to the customer at his/her 
Push Dock(s) 38a, 38b... 38n associated with the chosen 
channels. Throughout this discussion and the Figures it 
must be appreciated that each customer may have multiple 
channels associated with it (e.g. a Personal Computer's 
modem telephone number, beeper number, a fax number) . 
Furthermore, the Push Banking system of the present 
30 invention can simultaneously support multiple channels 

for each of multiple customers. 

As shown in Figure 4B, the Push Active Filter 
3.0 awaits a response from the Push Docks 38a-38n of the 
customers from which it expects to receive such a 
response over any one of the Push Channels 36n. The 
Response 46 is communicated over the appropriate Push 
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Channel 36n so that it may be received by the Push Active 
Filter 30. This information is then transferred to the 
existing banking system in the form of an incoming 
transaction 14 which is then processed by bank processing 
section 12. Any piece of information may be sent over 
several Push Channels 3 6a-36n to a customer or several 
customers. Information received from customers, as 
illustrated in Figure 4B, is transformed into standard 
bank transaction format for input into the bank 
transaction input stream 14 as its shown in the Figure. 

From the perspective of communication with 
customers or the public, the mode of communication of the 
present invention differs from the modes of communication 
used in -traditional Push Technology in the ways depicted 
in Table 1. 
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Push Technology 


Present Invention ■" V £'":Y" 


tied to the Internet 


not dependent on the 
Internet 


TCP/IP communications only 


virtually all forms of 
communications incl . 
TCP/IP 


unidirectional 


bi-directional - includes 
Response capability 


low security 


security as appropriate to 
product risk 


security passive 


security active 


not persistent 


persistent 


one communications channel 
} : 


flexible multichannel 
communications 


1 fiinqle channel 
| con? iguration 


many channels 

reconf igurable on the fly 


i £.-v;ie target device 

I 


many target devices 
selectable on the fly and 
simultaneously addressable 


ctsolete messages persist 


actively removes /corrects 
obsolete "Pushes" 


unaware of message receipt 


aware of message receipt 
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A high-level perspective of <-h- 
components and techn ology architIL 

the present invention printed °* ^ ° f 

layo Ut is shown in Pig!™ " * ^ ° f 

Figure 5B depicts ■ fv™» ■ . 

30 of the present invention ^ !" ACtlVe " lter 

includes three „a jo r oomponents^toeT^ 

Decision component « <pL,T ^ *T* A<=tive *«*«. 

FUter Ministration Componen^^^^ 

_ _. ..consist? of -a Bank tv-~ iit- - - - 66 --- ; -The_PAFDG 62 

components .■aTLtT^ ^ 

ba«d on a set of rules creT tranSactions ««> then 

« P-es Nation atrsntrietJTh ^ PAFCC M 
push bock and is responsible for" 7 channe i* to the 
=»sto„er in the case of TZJ^JT"**'^ «» 
responsive for determini„ g ^„? c rcL° nSe ; ' " *" * 1S ° 
depending on the customer Lit i^ t0 USe a " d 

Different models for pafdc 
correspondence are po Ssible 1 * and PAFCC 64 

[ 5 possible model a Tne t SeCti ° n SPea * S to one 

and PAFCC 64. 'm this m °7°" e COrres P^ence. of PAFDC 62 

communicates with to o„ e Id'onT" ^ " 

The basT! ^ PAFCC 64 in ^ance. 

- instance oper^ ^ /d^^ 9 ^ ™* 

customer list » „ . fl "' te set of the total 

' « instances." Th i Til T^t,^ 

interact directly info , "»*<'-» *» not 

Quired for L"L deci " ^ A is "-er 

customers in t^V^ at^T^ " ' " "~ 
buying an instrument that- „ * irectl y/ as by customer a 

-ct is reflected ^ ITZZ L^" 1 "*' ^ 

rusn Banking system,) 
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The set of customers processed by a given 
PAFDC 62 instance must be made small enough so that: 1) 
the PAFDC 62 program can process all the information 
about all the customers in the set in a reasonable time; 
5 and 2) the corresponding PAFCC 64 instance will be able 

to process a 11,. the downstream and upstream messages to 
and from the docks in a timely manner. 

, PAFDC 62 and PAFCC 64 instances can be 

distributed across multiple host machines as seems 
10 appropriate and desirable. A shared directory or other 

means of interprocess communication as required by a 
specific implementation must be provided for each pair. 

Business unit systems within an organization 
(e.g. a bank) are presumed to provide information about 
customers as a database accessible to all PAFDC 62 
instances. It is the responsibility of a particular 
PAFDC 62 instance to search all accessible databases 
across all business units to gain the necessary 
information to process its set of customers, possibly 
employing intelligent agents located at the databases. 
The PAFDC 62 is also responsible for keeping a profile on 
each customer, identifying the Push Banking wide customer 
ID with business-unit-specific account numbers or other 
indicatives. 
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Some business units may wish to export a stream 
of alerts reflecting critical business events. m this 
case, the alerts are sent directly to the customer's 
PAFDC 62 for immediate entry into the outbound queue. 

Figure 6A depicts the main architectural 
30 component of Push Active Filter 30. One of the functions 

of Push Active Filter 30 is to monitor bank transactions 
and based upon a set of rules, decide if a customer needs 
to be contacted, and if so, creates a "Push". 

The Push Active Filter Communication Component 
64 serves to push information across a variety of 
channels to the Push Docks 38 and is responsible for 
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communication with the customers -42 in the case of a Pus h 
Response. xt is also responsible for determining whilh 
channels to use depending on the customer profits The 
Push Active Filter Communication Component V^FCC, 
performs the following main functions : 

n . . 1} Receiving a Push from the PAF 

Decision Component 62; 

2) Selecting Push channels based on 

customer channel profile tino nf ^ ° n 
\_ fc ^ ie ' rime °f day and, if desired 

customer location; and aesirea, 

_ 3) Formatting messages appropriate to 

Acknowledgments from Push Doc*' (i.e.. arrived a t Doc*,. 

. MM9es " a^T tY netWOrk ^-""n. truncating 

messages to a lowest common denominator designed to 

the customer aware of a Push situation. "** 

Part of each customer's PAFCC 64 profile will 
include a list of code numbers represent™ , t 
V not to be sent via certain 121 

■n Edition, the P AFCC .^X^^^^- 

««Pt, This allows the system to avoid sending lower- 
.Pr.oritv messages, via intrusive doCcs such' as page" 

Customers may elect to implement the following 



features : 



Send-Also profiles, which include a list 
c r Persons (and their associated devices, to which 
messages will also be sent; ' : 9 

Send-On-Failure profiles, which direct a 
— ,e to another person in the event ^hat a 
cp^xcations failure is detected either from the 
c-Hsunxcations channel or an end device; 

Send ' Instead Profiles, which allow 
r«.« gnment of messages from Customer .ones to Customer 
S»ith. based on Smith's Do Not Send profile; and 
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Send-Escalated profiles, which send 
messages to persons on the list in the event that a 
response has not been received within a specified period 
of time. 

5 The PAF Administration Component module 66 is 

primarily responsible for: 

1) Maintaining Customer Communication 

Profiles ; 

-2) Maintaining Push Transaction history 

10 files; 

3 > Reporting on Push Banking Message 
Traffic and Transactions Generated; and 

4) Reporting on Error Situations, Pushes 
Outstanding and Lapsed Pushes (Pushes which were not 
responded to before they became "stale."). 

The process flow of capturing a customer's 
profile by the PAF Administration Component Module 66 is 
depicted in Figure 12. 

The PAFCC 64 employs databases that not only 
maintain these, profiles but also serve to consolidate 
customers' accounts with a single identifier. The PAFAC 
66 also utilizes Push Technology to detect incoming, 
customer-originated profile updates, issue a 
challenge-and-response communication and register the 
25 updated profile information. 

The PAF Error Handler 100 is responsible for 
resolving errors and assigning error codes. 

The PAF Channel Handler 54 is responsible for 
determining through which channel (s) information should 
30 be pushed through. It determines the appropriate 

channels based on the customer's profile 106. 

The PAF Cleanup Handler 52 is responsible for 
maintaining the status of the various Push Docks 38 by 
modifying (i.e., adding, deleting, or updating) them as 
needed as Pushes are responded to, become superseded or 
become stale . 
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The PAF Security Handler 58 is responsible for 
ensuring that an appropriate security mechanism level is 
used for each active channel. 

The PAF. Cleanup Handler 52 removes or cancels 
all messages passed on alternative channels after the 
customer has successfully responded via one of the 
channel. When a device's Push Dock becomes full, it 
initiates Push Message Cleanup which examines the 
messages in the Dock and removes, stale messages first. 
Should none be found, it removes the oldest, lowest : 
priority and responded to messages first . 

- The.. PAF. Communications -Layer 40 is responsible 

for the physical reception and transmission of 
information on the various channels. This module is part 
15 of the PAF Communications Component 64. 

The Security Component 58 of Push Active Filter 
30 is an integral design element of the system. Not only 
does Security Component 58 address all of the well known 
challenges of the Internet, but also the additional 
challenges of open wireless and landline communications. 
From a banking point of view, Security Component 58 
preferably may include any of the following security 
features . 

Mutual Authentication. The customer and the 
bank are mutually authenticated using the techniques 
specified in the Federal Information Standards 
Publication 196 -- Entity Authentication Using Public Key 
Cryptography. (This is the standard recommended to X9, 
the Standards Committee for Financial Services accredited 
by the American National Standards Institute (ANSI) , as 
an approved X9 standard) . 

Total Confidentiality. The confidentiality of 
all. messages/data communicated between Customer and Bank 
are protected by encryption using symmetric-key 
cryptography as specified in relevant ANSI standards. 
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Message Integrity. The integrity as well as 
non-repudiation of messages/data communicated between the 
customer and the bank are protected by digital signature 
using public key cryptography as specified in relevant 
5 ANSI standards. 

Key Management and Certificate Management. Key 
management and certificate management for the above- 
cryptographic services must use methods specified in the 
relevant ANSI standards. Also, the Push (the message to 
10 the customer) and the Dock are each signed (e.g. as a 

"signed applet" or by other means) and each checks the 
signature of the other. 

In addition to these standard techniques the 
Security Component 58 provides for an active defense of 
the system against attempts to hack or tamper with it. 
This method called Push Active Defense (PAD) is an 
innovation in the area of messaging security. The 
objective of PAD is to make potential malefactors totally 
uncertain relative to the success of their efforts versus 
20 the possibility of their detection. Any of the. following 

three basic techniques may be used in the preferred 
embodiment. 

1) Decoy Transmissions. This technique 
transmits decoy test messages to decoy Docks 38. Here, 
the present invention discerns attempted spurious Push 
transactions. Unauthorized personnel can get access to 
Docks 38 by monitoring Push traffic and transmitting to a 
Dock 38 directly. A significant amount of traffic is 
directed at Bank maintained "dummy" Docks 38, so that a 
unauthorized personnel could be as likely to attempt to 
remotely penetrate the dummy Dock 38 as a real one and in 
doing so immediately set off an alarm at the Bank and a 
series of defensive measures designed to identify and 
capture the unauthorized personnel. 
35 2 ) Transparent Transmissions. This technique 

transmits "transparent" test messages to active Docks 38. 
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Here the present invention silently discerns any 
ta^perxng with existing valid Docks 38. Unauthorized 

frTZ ^ ^ D ° CkS 38 ^ ° btaining to one 

rrom the customer's side re n • 
c o ( g * stea lmg a PDA). Push 

5 security component 58 sends test validation Usages 

transparently (i.e. without revealing the message to the 

These test messages require the Dock 38 to respond 
correctly. if it aoes not , ^ i Mediately sats 

" off an alarm at the Bank and a series of defensive 
measures designed to identify and capture the 
" " UnaUth ° r " e ' i P*"°™^ 0r to ideniif y " a - - talled Doo -- - 8 - " 

3) Push and Push Dock 38 Mutual 

15 ^T r l ni T i0 " " - «tablishes a mutual 

ZTTT r /synohToniZ3tibn process «» 

and the Dock 38 which is speciaUy designed to reveal 
tampering,, replay,, or denial of service attacks. 

Each Push and each Push Dock 38 has three 

,0 TsTl"^?: V S 3 2 " b " "-""""on number, b 
is a 18 bit selection number, and c is a 256 bit result 
number. A Dock 38 is initially seed . d wlth M 
numbers, a, b and c. 

th, p . , T 3 PUSh a "ives, the Dock 38 selects from 
T.l 3 Slg " atUre »»— ' " «t blocks based' on 

it Is „" T " le ° tl0n bit is 1- th. block is chosen, if 
it is o a block of eercs is chosen. The result is then 
XORed With the Dock's pre-seeded result number. The Push 
30 r n » Pe K rf ° raS ^ - °" the Dock's numbed 

Lsh t D ° 0JC " eX ° han9e " SUlt ™-»-~. ^e 

Push returns the new result to the Push Server in th. 

resu^ ?°" led9 ™ ent D ° Ck 38 "s new 

Push , f ° f *"* ° ld Pre — e ^ number. The 
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The following is a formulaic representation of 
this process where PID is the Push identification number 
PSEL is the Push selection number, PRES is the Push 
result number, PDID is the Push Dock identification 
5 number, PDSEL is the Push Dock selection number, and 

PDRES is the. Push Dock result number: 

Tempi = PDSEL (PDID) XOR PDRES 
Temp2 = PSEL (PID) XOR PRES 
PDRES = Tempi 

10 PRES = Temp2 (used in Push Ack) 

PDSEL = PSEL 
All initial numbers are randomly generated. 
PIDs and PDIDs, while randomly generated, are made unique 
to each Push and Push Dock respectively (i.e. a randomly 
15 generated repeat of a previously used number is discarded 

and a new random number is generated) . The Transparent 
Transmissions described above resynchronize each Dock 38 
just as if they were actual Pushes. 

The Push Banking Server has knowledge of the 
20 true current and future states of all six numbers. If 

someone were to attempt to create a valid Push or Dock 38 
by copying or replaying and did not have access to all 
six numbers, he or she would have virtually no chance of 
computing a good result number, a replay would simply 
25 produce a message with an already used result number. In 

either case, the present invention would not "fail" the 
message because of bad authentication but rather would 
begin to initiate PAD. countermeasures while lulling the 
unauthorized personnel to think that the attempt was 
30 successful. 

This method has the additional unanticipated 
benefit of being completely, effective in an environment 
where Pushes could be received in an order different from 
which they were sent. The Server immediately realizes 
35 what has happened and resynchronizes on the fly. This 
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provides a flexible alternative to standard message 
serial numbers. 

The length of the numbers a=256, b=16, c=256 
may be increased or decreased to create more assurance or 
5 accommodate a more limited environment respectively. in 

all cases, a must equal c and b must divide a and c 
without remainder. 

In the present invention, security is applied 
selectively depending on the risk associated with a 
10 particular message (i.e., a Push or a Response) , the 

channel and the Dock. 

- - — Decision Component 62 -is the, part of 

the system which decides if and when some piece of 
information must be pushed to a customer. The Decision 
Component 62 performs at least the following functions: 

1) Monitoring accounts, transactions, etc. 
versus general Push profiles and customer supplied Push 
profiles (e.g., account is about to go overdraft - do a 
Push, customer wants to be pushed any debit greater than 

20 $100,000, etc.). 

2) Deciding if a Push is required (i.e., meets 
one or more profile criteria). 

3) Examining all other available customer 
information to determine possible Push Response options. 

4) Passing Push messages and Push Response menu 
to the PAF Communications Component 64 (PAFCC) . 

The following section describes in more detail 
the PAF Decision Component 62 in reference to Figure 6B. 
The PAFDC 62 consists, at the highest level, of four main 
30 components: the PAFDC Situation Monitor 68 which scans 

for or receives from sources of information for items of 
data relevant to a possible Push; the PAFDC Decision 
Maker 69, the decision making component which decides if 
a Push should be made; the PAFDC Push Packager 70 which 
35 formats the Push in a way compatible with the 

transmission requirements of the PAF Communications 
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Component for a customer's device or list of devices to 
which a Push is to be sent; and the PAFDC Prioritizer 71, 
which assigns a relative priority to a Push based on the 
context of current Push messages that have not been 
5 responded to. 

The PAFDC Situation Monitor 68 includes an 
Interface Handler which manages access to existing bank 
files and records. 

PAFDC Decision Maker 69 also includes a Rule 
10 Acquisition subcomponent which a) enables it to scan 

previous days' data and other information to create new 
decision rules through machine learning and b) accepts 
operator entered rules (e.g. customer specified Push 
- preferences) . 

15 The Rule Acquisition subcomponent could be 

represented by a person who maintains the rules and 
integrates new trends and resolves conflicts with current 
assumptions. 

The PAFDC Situation Monitor 68 is responsible 
20 for scanning data available from or received from: 1) 

customer account files; 2) transaction files; 3) bank- 
maintained statistical and analytical files; 4) 
consolidated files and alerts from other banks which 
relate to the Push Banking System as a concentration bank 
for a particular customer; and 5) external information 
sources. When monitoring external data sources, 
linguistic processing engines may be useful to ensure 
that messages are triggered in the context the customer 
intended. 

The PAFDC Situation Monitor 68 scans the Bank's 
files as transparently as possible - ideally without 
interacting directly with the underlying Bank systems or 
without requiring modification of those systems. 

All information received from consolidated 
35 files and alerts from other banks which relate to the 

Push Banking System as a concentration bank for a 
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particular customer are be maintained by the Situation 
Monitor .68 until it is superseded by fresh information or 
end of . day /beginning of day conditions. 

External Information sources are monitored 
5. through a traditional Push Technology system under a 

profile supplied by the Push Banking system 
administrators. The profile criteria of Push Technology 
(PT) system is synchronized with the set of external 
information items available to the Situation Monitor 68. 
10 As information appears from the PT. system, a subroutine 

posts it to the appropriate internal data . item. For 

instance, _if_unrest appears, in an. emerging- nation, -an 

indicator and a pointer to a brief descriptive text is 
posted to that nations' data. item. Market . pricing data 
15 is also posted. 

All information sources are scanned on a 
regular basis. Higher volume, more volatile or more 
critical information is scanned at a higher frequency 
than other data or communicated through immediate alerts. 
Frequencies of scans are synchronized so that each lower 
frequency divides evenly into the next higher scan 
frequency. For example the lowest scan frequency might 
be once in ten minutes, followed by every 2 minutes, 
every minute > and every half T minute for various categories 
25 of data. After each highest frequency scan (e.g. every" 

half minute in the previous example) all scanned data is 
.., posted to the PAFDC Decision Maker 69 on a customer by 
customer basis. 

A second component of the PAFDC Decision Maker 
30 69 is a Rule Acquisition system which a) enables it to 

scan previous days' data and other information to create 
new decision rules through machine learning and b) 
accepts operator entered rules (e.g. customer specified 
Push preferences) . 

The PAFDC Decision Maker 69 consists in part of 
a rule-based Artificial Intelligence system using the 
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concepts disclosed in US Patent 5,259,066 and in the 
paper Neural Nets v. Expert Systems in Real Time Systems 
presented at the IEEE Electron /93 International 
Conference or, depending on the specific implementation, 
5 other decision making processes such as database stored 

procedures or application logic. Scanned data from the 
Situation Monitor 68 is posted to the Decision Maker 69. 
The data item is called an attribute in a rule based 
system and its content is called its value. The output 
10 of a rule based system is called an action. Actions are 

input to the PAFDC Push Packager 70. 

Decision processing in the preferred 
implementation of the invention is rule-based. Each 
function requiring decision processing is characterized 
15 as having a specific set of attributes with defined 

values that uniquely determine what action the function 
must perform. As these attributes take on different 
values, they match one of a set of rules in the function* 
A rule that matches the set of attribute values is said 
20 to "fire", and a rule that "fires" causes the action 

associated with the rule to be performed. 

Each rule is defined as having the form: 

A*B*C *K, where A,B,C,^.K represent the attributes 

that may take on one of two or more discrete values. The 
25 operator* represents the logical "AND" function such 

that the rule is "true" (fires) only if every attribute 
in the rule simultaneously equals the value specified for 
tno attribute in the rule. Each rule contains only those 
attributes necessary for the definition of the rule. 
30 Tn-js, attributes omitted from a rule can not influence 

t:.« firing of a rule. 

Attributes that must reflect the effect of 
ccr.t muous values are assigned discrete values based on 
^r.;ch segment, within the allowable range of values, that 
35 trie value lies. For example, if the attributes are to 

represent in which of eight segments a bank balance lies, 
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three binary attributes could be assigned to represent 
the eight segments with the standard 000, 001, . . . , m 
binary encoding or decimal equivalent. 

The rules in a function are mutually exclusive. 
That is, by design each rule differs from every other 
rule in the rule set for that function. As long as at 
least one attribute value in a rule differs from the 
value of that attribute in another rule, the two rules 
can not "fire" at the same time. Thus, each rule in the 
rule set must have at least one attribute in common with 
each other rule of the set, but with different values for 

the attribute in common. It is therefore assured that 

only one action will be performed by the function at any 
particular point in time. The decision process always 
15 makes a uniquely defined decision as to which action 

should be taken. 

Although the rules are mutually exclusive, more 
than one rule may specify the same action. This provides 
the logical "OR" function implicitly. Contextual 
interpretation of the attributes is provided by defining 
contextual attributes that are set by certain rules and 
reset by other rules. Incorporation of these contextual 
attributes in rules provides contextual interpretation of 
the other attributes contained within those rules. 

The decisions made by Decision Maker 69 are 
made synchronously with. a. timing signal so that the 
attributes may change values, asynchronously between 
decision time points with no effect on rule firing. 
Rules are only permitted to "fire" at the designated 
decision time points. 

. The interface of a generic decision processor 
within a function consists of the attribute value inputs, 
timing signal, and action, output signal. 

In a preferred embodiment, the rule set is 
35 implemented as a decision tree in order to avoid 

searching through the rule set for a match. Since the 
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rule set contains only mutually exclusive rules, a single 
tree can be constructed with no ambiguity. The order of 
occurrence .of the attributes in the tree is selected in 
the order of increasing generality so that the most 
5 efficient tree is built. The attribute occurring most 

often in the rule set is placed first, at the root of the 
tree. This process is repeated for the remaining 
attributes, placing the next most frequently occurring 
attribute next in order, until the order for all 

10 attributes' is established. When more than one attribute 

occur the same number of times in the rule set, they are 
placed in the tree sequentially in arbitrary order 
following the previously selected attributes in the order 
established above. The terminus of each branch (leaf) 

15 designates the action to be performed by the function. 

An Automated Rule Acquisition System of 
Decision Maker 69 operates in batchmode against the 
previous period's information (e.g. day, week, month) as 
it appears today in the attempt to f ind Push 

20 opportunities that were missed in regular Push Banking 

processing. 

Further envisioned in the preferred embodiment 
is self -evolution of the rules. This is implemented as a 
set of meta rules that recognize inconsistency between 

25 prior experience and current occurrences. The meta rules 

embody reasonableness tests to detect aberrant behavior 
and the forming of new trends. As new trends are 
confirmed, the meta rules provide the instructions for 
modification of the decision tree that performs the day- 

30 to-day decision processing. The meta rules themselves 

are also implemented preferably as a decision tree. The 
actions invoked by the meta rule tree cause insertion and 
deletion of attributes into the day-to-day decision tree, 
and edit existing action procedures or create new action 

35 procedures that are selected by the day-to-day decision 

tree leaves. 
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The iaeta rules are particularly sensitive to 
manual override of 1 the generic decision processor. This 
enables the automatic incorporation of changes introduced 
on a regular basis by the system operator. Since manual 
5 correction normally signals a change in procedures or 

other system modification, this automatic adaptation 
reduces the required maintenance efforts usually needed 
for automated decision processing. 

A Manual Rule Acquisition system of the 
10 Decision Maker 69 allows direct input of rules by a duly 

authorized operator; Such rules are generated prior to 

. the first -operation of- Decision-Maker 69 through customer " 

submitted Push requirements and at the introduction of 
new Banking or Push Banking products and services. 
15 PAFDC Decision Maker 69 checks any Push 

recommendation against those already transmitted. Any 
new Push will be given to the PAFDC Push Packager 70 for 
processing. 

The PAFDC Prior it izer 71 is responsible for 
assigning a relative priority to each Push based on the 
other Pushes being generated how and the outstanding 
Pushes that have not been responded to. 

It is possible that a customer has been sent 
from l to n Push messages that may or may not refer to 
the same topic. In order to ensure that the most urgent 
messages reach a customer first, the PAFDC Prioritizer 71 
©famines the list of messages that are currently 
outstanding (those that have not been responded to) and 
associates them by topic and ranks them by priority. It 
JO then examines the topic and priority of the message 

currently being constructed and assigns a priority to the 
new aessage. This is performed by employing decimal 
frictions, wherein a priority of 0 (not used) means a 
escssage should never be sent at all and 1 (not used) 
5 ffieans it should have arrived yesterday. Thus, to insert 

a cessage in the priority queue between a .7 message and 
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a .8 message, a value of .75 is assigned; to insert 
between .7 and .75, a value of .725 is used, etc. The 
PAFDC Push .Packager 70 formats the push decision in a way 
compatible with the transmission requirements of the PAF 
5 Communications Component 64. It does this using the 

"Action" pointers designated by the PAFDC Decision Maker 
69 for text message components for the various Push 
situations. The Push Packager 70 takes the text message 
components, the customer identification information, and 
10 the scanned data and composes a full Push message, which 

is then passed to the PAF Communications Component 64 for 
further formatting and transmission in priority order. 
The Push Packager 70 performs analogous formatting when a 
Response is translated into a Bank transaction 12. (See 
15 Figure 6A) . 

A significant aspect of the present invention 
is its bi-directional form of communication as compared 
to the unidirectional nature, (i.e. server to client) of 
traditional Push technology 
20 The present invention is not unidirectional 

(i.e. server to client) as is Push Technology. 
Accordingly, an integral part is the Push Response. A 
Push. Response is the component that allows the customer 
to react in a timely and effective fashion to the 
25 information received through Push. The Push establishes 

a Push Response mechanism that is enabled by the Push 
Dock. A Push Response from the customer is answered 
through a Push Response Acknowledgment from the Push 
Active Filter 30. Subsequently other acknowledgments or 
30 advices produced in fulfillment, of the instructions of 

the Push Response can also be Pushed back to the customer . 
as required. 

Another feature of Push Response, is that it 
leverages all security features of the device that 
35 received the Push. The most sophisticated devices will 

send three acknowledgments: 
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First, a machine acknowledgment shows only that 
the customer's dock has received the message. This may 
consist, for those docks using TCP connections, only in a 
successful TCP socket close action. 

Second, a customer acknowledgment shows that 
the user of the dock has successfully decrypted the 
message (if it was encrypted) and has displayed it. It 
is presumed that if the message has been displayed, the 
customer has read it. 

Third, a message response is sent when the 
customer has decided what action to take. 

If all jthree ^acknowledgments -cannot be sent -by — 

the device, the customer will be sent (at their option) 
1) a simple message that directs them to call Customer 
Service, which will then verify the customer's identity, 
or 2) a message that directs them to call Customer 
Service but also contains code words that the customer 
has registered as indicating given scenarios. An example 
of the use of code words is: a customer registers that 
code word "Tomato" with the topic "Asian Markets" and the 
code word "Burning" with the action "fallen ten percent". 
When a Push condition indicating that Asian markets have 
fallen ten percent has occurred, the customer will 
receive a message stating "The tomato is burning — 
please call your Customer Service representative". Code 
words need not be restricted to words and phrases; in the 
above example, a customer could have chosen the string 
"423" with "Asian Markets" and "001--0" with "fallen ten 
percent", resulting in a message consisting of "423 001- 
30 00 -- please call your customer service representative". 

Further expanding the notion of bi- 
directionality, customers are able, (depending on the 
capabilities of their devices), to self-administer their 
user and interest profiles in a safe and secure manner. 
Examples of user profile administration include the 
customer's ability to change its preferred registered 
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device (for example, from pager to PDA) and contact order 
(for example, send first notification to PDA, second 
notification to pager, etc.)- Examples of interest 
profiles include the customer's ability to change the 
5 topic and relative importance of items of interest (for 

example, never contact if checking account becomes 
overdrawn?; send highest priority message if Asian markets 
fall by a given percentage, etc.). 

The following section describes the high-level 
10 application functionality of the PAF Communication 

Component ' 64 . 

The PAFCC 64 is capable of sending the 
following message types: Standard messages to the end 
user;' Process ACK messages to the end customer; and 
15' , Requests for message status. 

In response to any of these message types, 
docks can return: Standard replies from the end 
customers; Customer Initiated Messages; and Message 
status information. 
20 As shown in the block diagram of Figure 6C, the 

PAFCC s 64 first task in sending a message is to use its 
Input Parser to retrieve pending messages , in the form of 
a record 122, for example, from its paired PAFDC 62, and 
validates them. For example, to pass as a valid XML 
25 communication, a PAF message must have: A valid start 

(<PAF>) and end (<\PAF>) tags; One currently unique 
message identification (<ID>) ; One valid customer to send 
to (<to>) ; and A valid priority (<pr>) value; and a non- 
null message to be sent. 

If a message does not pass through the 
validation procedures for its format either in Input 
Parser 120 or the Transmit Record Formatter 124, an error 
is returned 126 to the PAFDC 62 via the Response Router 
128, with the problem or problems fully detailed. 

Validated messages are next logged, with their 
status, in a persistent data store 130 for transmission. 
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Messages that have a response or have gone stale are 
moved to the PAFCC activity log. At this point a return 
126 is sent, to the PAFDC 62 with the message status. The 
PAFCC 64 automatically performs clean up on those Docks 
5 132a-132d that support it. After a response has been 

processed, docks 132a-142d whose status indicates the 
customer hasn * t read the message can' remove them from the 
docks queue. If the message has already been read on 
another than the responding dock, the return values are 
10 hidden and a value of u Responded To* is set in its 

place. Lower level docks will only receive an 

acknowledgment -at- the -end -of- processing. Second 

responses and post stale date responses generate an error 
message to the PAFDC 62 and a PAFCC 64 log entry. 
15 Priority, as logged from the PAFDC 62, plays a 

role when there is competition for limited resources. At 
any point that the PAFCC 64 sees a collection of records 
to process, it reorders them by the criticality that they 
be transmitted immediately. ' in addition to priority, the 
20 PAFCC 64 knows the origination time and data of the 

message, its current status and its lifetime. Each 
message has a stale date that can be qualified to the 
second. Criticality is based on all of these factors. A 
lower priority message with a 1 short stale date could be 
25 processed before a higher priority message with a much 

longer valid time. 

The PAFDC 62 sends messages in bursts after 
scanning its entire customer list. All the messages in 
the burst are processed by the Input Parser 120. Then the 
30 Record Formatter 124 sends them in criticality order. As 

each message is processed it is mated in the Transmit 
Distributor 134 with customer transmission data 136 from 
the Customer Records; 138; Since these new' messages have a 
new or not-sent condition they queue up immediately for 
35 transmission. This makes any particular customer's 

messages transmit in priority order. 
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The type of dock 132a-132d controls how 
messages are handled from the time it is received by a 
channel to the time it is cleaned up. All processing 
calls (for example, send, status, return and so forth) 
5 are. modified by the dock 132a-132d according to its type. 

The highest level docks 132a-132d have a client side 
component that can fully interact with the PAFCC 64 to 
support update, and change functions. These docks can 
actively tell us 1) what they've received, 2) if the 
10 _ customer has viewed the message, and 3) the customer's 
responses. If messages haven't been responded to, an 
update can be applied at the dock and displayed when the 
customer is . available. The message can be canceled, if it 
hasn't been displayed and another channel has responded. 
15 At the next level are docks that support two- 

way communications and guaranteed delivery. PAFCC 64 can 
tell if the device has received the message, but not if 
the client physically has the device. Usually the dock 
132a-132d must be polled for status. The order of 
20 display is the order of actual transmission. There is 

usually a service (e.g. a telecommunication system) 
between the Push system and the dock. Depending on the 
complexity of the service interface, messages may be 
canceled or otherwise manipulated. These docks may 
25 require new transmissions to keep the customer v 

up-to-date. This is especially true if a response is 
received after its stale date has been reached. 

If a one-way dock is used, the responses are 
handled by the customer service system. The Customer 
30 Service (CS) representative must be able to call up a 

historical and current view of the message while 
. conversing with the customer. When CS closes a message 
they have a higher validity than dock messages. For all 
types of communication, the only way a customer can 
35 change its decision is through CS. Docks that cannot 

guarantee delivery may be retransmitted at a rate 
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determined by an algorithm in the PAFCC 64 distribution 
system. - 

Eor more capable docks, the PAFCC 64 receives 
acknowledgments and sends, three kinds of responses back 
5 to the PAFDC 62 ,: 1) response received but the Push is 

stale, 2) response received, 3) response received and 
transaction processed* . : . * 

The PAFCC 64 has a reprioritization function 
which is responsible for re-ordering messages based on 
10 current priority and their nearness to their stale dates. 

The PAFCC 64 also detects logjams in the 

sending stream If , over ^ a p er i od of -time messages 

cannot be sent optimally fast,, the PAFCC 64 will 
construct new and shorter messages and try to send these 
15 to their destinations. ; 

If the service standard for message 
transmission continues to be sub-optimal, the PAFCC 64 
will alert the system operator or carrier personnel 
automatically and proactively and direct them to begin 
20 tracking down the cause of the logjam. 

The following section describes the 
functionality of the present invention at the customer 
end. Figure 7 depicts the various components of the 
customer end architecture. Each component is described 
25 below. , • 

In addition to. supporting a multiple user 
interfaces for each platform (physical device) , new 
services will constantly be introduced which will require 
modular construction of the system. 
30 The architecture of the customer side of the 

present invention enables a customer to receive 
information via a Push from the bank and then be able to 
respond. The types of physical devices which can be used 
by a customer include, but are not limited to: Desktop 
35 Computer, Laptop Computer, On-line Terminal, Network 

Computer, Personal Digital Assistant, Programmable 
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Cellular Phone, Programmable Two-way Pager, Interactive 
Cable TV, and Interactive Satellite TV. 

In addition to the wide range of physical 
devices that must be supported, the present invention is 
also not dependent on one topology. The system works 
over the following: . Internet, Intranet, Extranet, 
Telephone networks, Wireless Networks, IP, Networking 
Protocols,. Satellite Protocols, and Cable Protocols. The 
above list is not exhaustive and is intended to include 
new programmable devices and channels of communication as 
they become available and as support for combinations of 
devices and channels evolve, 

' Additionally, the present invention is intended 

: to be accessible via a dial-in response to the bank 
customer service system by the customer once they are 
contacted. These services consist of the bank system 
-contacting the customer via one of the following methods: 
telephone, telegraph, fax, beeper, one-way cable TV, one- 
way satellite, dial-out terminal, on-line terminal, 
Internet, Intranet or Extranet, SmartPhone, 2 -way beeper, 
Personal Digital Assistant (PDA) , Personal Computer (PC), 
express mail delivery, commercial express delivery and 
various systems of the type mentioned above. The list 
above is not exhaustive and is intended to be expanded as 
new programmable devices become available. 

. The following table brief ly describes the form 
the Dock may take for each delivery mode. 



41 



BNSDOCID: <WO 9930295A 1_l_> 



WO 99/30295 



PCT/US98/25154 



10 



IS 



20 



25 



30 



Push Channel 

mail express delivery. 



Push Dock 



enclosed 2-way beeper or 
PDA ^ 



commercial express 
delivery 



*fax 
*beeper 
**one way cable TV 



**bne' way sat el lite " tv 
***dial up terminal 

***Internet, Intranet or 
Extranet clien t 

***SmartPhone 

***two-way beeper 

***personal digital 
assistant (PDA) 

***interactive cable T V 

***interactive satellite 
TV 



enclosed 2-way beeper o 
PDA 

online voice or tone 
response 

dial in response 

<iial in response 

dial in response 



dial in response 
interactive response 
interactive response 

interactive response 
interactive response 
interactive response 

interactive response 
interactive response 



- . With reference to Figure 7, there are shown 
various software blocks for use ,'t the customer side of 

user C i7T a " 0n Path ' Th6Se in< = IUde the ^—tioned 
user interface 80 and software which implements such 

functions such as Push Response 82, push Doc* 84, Push 
Channel ... Push Administration 88. Error Handle; so and 
■a Physical Communications Layer 92 . 

The user interface module 80 is only applicable 
to programmable customer devices . Depending on the 
target device, the user interface ranges from displaying 
a- Simple text message (e.g. beeper text messages, to a 
compiex graphical interface (e.g. Web browser, . As much 
possible, common standard technologies are employed to 
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implement the user interfaces. These technologies 
include, but are not limited to, Java, HTML and HDML (the 
hand-held markup language from Unwired Planet) . 

Personal Computers (PCs) , Personal Digital 
5 Assistants (PDAs) } offer the most functionality and 

complexity of any devices. Due to amount of available 
memory and storage capacity, these devices preferably 
employ a memo jry ; resident program which monitors incoming 
Pushes; and use a display large enough to display 
10 messages with a minimum of scrolling. 

Two-way Pagers and SmartPhones are categorized 
by their ability to send responses back to a server. 
Additionally, some devices have the ability of storing 
applications. For the present, these devices are limited 
15 to responding to a series of Pushes in a serial fashion. 

The Push Dock module 84 is responsible for 
receiving, validating and storing messages from the Push 
Active Filter 3 0 (see Figure 3). Push Dock 84 and Push 
Response 84 (which also contains executable code) 
20 together enable the customer to view messages and make an 

appropriate response. This storage functionality is local 
if the physical device supports persistence storage. 
Otherwise the system stores the Pushes on the server end 
cf the Push Channel 86. Two options exist for available 
25 docking space at the Customer end. l) pre-allocated size 

- meaning a fixed amount of space for Pushes and 
Cleanups; or 2) an amount of available space signaled by 
system - meaning a variable but not infinite number of 
Ksnes and Cleanups can be accommodated. Either 
30 s;tuation can require a "Dock Full*' message from the Dock 

84 to the PAFCC 64 (see Figure 5A and Figured 5B) . 

The Push Channel 86 in Figure 7 is the logical 
«r-.j physical communications media between the Push Active 
r liter 30 (Figure 3) and the customers' Push Dock 84. 
3 5 Tr.e channel 86 is analogous to a telephone line and 

network, where the line transmits the call and the 
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network routes it. The Internet is a Push Channel 86 as 
are two way wireless communications networks and 
interactive cable TV networks. ; Multiple channels may be 
supported for a single customer. As new 
5 telecommunications services are introduced , they may be 

accommodated by a separate Channel 86. 

Figure 8 illustrates the two types :of Dock 
memory models, where 97 designates a fixed memory, 
multibay type of Dock and reference numeral 99 indicates 
variable memory, single bay, -piggyback- type. of docking. 

Figures 9A and 9B contain illustrations of some 

of. the- types- of possible messages on a Push Channel" i 6 ~ " " 

including their direction (PAFCC to Dock or Dock to 
PAFCC). 

15 As shown in Figure 9A, several types of 

messages are possible relating to Pushes including a Push 
200, from the server (bank) to the dock (customer); a 
dock acknowledgment 205 of the receipt of Push (from the 
dock to the server); a Push Response 210; and a Response 
20 acknowledgment 215. Figure 9B shows messages related to 

cleanups, 220, 230 and a Dock Full message 235. 
Similarly, Figure 10 depicts possible Nack negative 
acknowledgment messages 240, 245, 250, on a channel 
including their direction. 
25 Table 2 telow is a list of possible states of a 

Push Dock relative to Dock and Channel type: 



44 



BNSDOCID: <WO 9800295A1J_> 



WO 99/30295 PCT/US98/25154 



Table 2 



10 



15 



20 



25 



30 



Push Channel 



^Puslt DoeJt 



interactive 
satellite TV 



set top +SW 



interactive 
cable TV 



set top +SW 



personal 
digital 
assistant 
(PDA) 



PDA + SW 



two-way pager 



two-way 
pager +SW 



smartphone 



smartphone 
+SW 



Internet, I Internet, 

etc. customer I etc. 

customer 
+SW 



online 
terminal 



online 

terminal 

+/-HW/SW 



(Push)? 



■=:- : ( Cleanup 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1-2-3-4 



1X-NA-3-4 1-2-3-4 



dial up 
terminal 



dial up 
terminal 
+/- HW/SW 



one way 
satellite TV 



one way cable 
TV 



one way pager 



fax 



telephone 



set top 
+HW/SW 



set top 
+HW/SW 



pager 



fax 



none or 

answer 

machine 



Possible Dock States 
(Push) : 0) no Push, 1) no 
ack, IX) some systems 
provide ack, some do not, 
2) no receipt, 3) no 
response, 4) response 



1X-NA-3-4 



1-2-3-4 



1X-NA-NA-NA l-NA-NA-4 



1X-NA-NA-NA l-NA-NA-4 



1X-NA-NA-NA l-NA-NA-4 



1-NA-NA-NA l-NA-NA-4 



NA-NA-NA-4 l-NA-NA-4 



Possible Dock States 
(Cleanup): 1) Push, 2) no 
cleanup ack, 3) cleanup, 
4) cleanup explain 
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; Referring back to Figure 7, Push Administration 
Handler 88 is responsible for general administration of 
the customer profile. it is specifically responsible 
for: cleaning up a Push after it has been transmitted, 
administrating multiple responses, biding the Push and 
Dock, and sending the response. 

The Push Response Handler 82 is responsible for 
processing the appropriate acknowledgment codes and 
formatting the response. The response uses a security 
algorithm and a Push specified communications protocol 

s The Error Handler 90 is responsible for 
resolving errors and assigning error 7 codes. 

The Physical communications layer 92 is 

responsible for the actual recpnf-ion i: . 

. • wcuetx reception and transmission of 

information on the customer side. 

Spontaneous upstream messages are messages sent 
by a dock (at the customer's request) to the paf 30 that 
are not in response to a Pushed downstream message. 
These messages can be used to communicate the customer's 
desire to change a PAFDC 62 or PAFCC 64' profile element. 

The PAF 3 0 does not act upon the request 
mediately. Instead, the PAFDC 62 or PAFCC 64 
(whenever is responsible for maintaining the particular 
. attribute. being changed by the customer) generates a 
" ?rMl do *nstream : message with text "You have requested 
changing (attribute, from (oldvalue) to (newvalue) . 
Conf irm?., and responses "Yes" (code = i) and "No" (code = 
C). ..Only if and when the customer responds with a normal 
< non-spontaneous) upstream reply saying "Yes" is the 
profile change actually made. The PAFDC 62 processes 
Fr-f He updates before or during its next firing cycle 
to ensure that the PAFDC 62 is acting on correct 
instructions. , . 

The following section will describe the process 
c. pushing a Push to a customer with reference to Figure 
: 1 • Assumptions for process depicted in Figure 11 are 

46 



BNSDOCID: <WO_9S30295A t 



"WO 99/30295 



PCT/US98/25154 



that the process flow is generic for any channel and that 
a Push is sent over multiple channels (e.g. beeper, 
Internet , etc . ) 

.. . In block 300, the PAFDC 62 (Figure 6B) monitors 
5 bank transactions, balances, derived analytical data, 

public and private ; data and data supplied to the system 
by. other banks in its role as the customer's 
concentration < Bank. 

,In. .decision block 305, if the PAFDC Decision 
10 Maker 69 determines that a situation satisfies a customer 

or general. Push profile, a Push will be sent. 

In block 310, the PAF DC 62 assembles the Push 
conten^ (i.e., Push statement detail and user responses 
scripts). The Push content is then handed over to PAFCC 
15 64 (Figure 6C) in block 315. 

In block 320, PAFCC 64 chooses the channel (s) 
based on the customer's profile. Based on the customer's 
Channel and Dock capabilities, the PAFCC 64 in block 325 
imbeds the Push content in a "Push" which in the ideal 
20 case is an applet or piece of code executable by the 

Dock. 

In block 330, the Push is formatted based on 
the channel (s) ' transmission protocols, and in block 335, 
the Push is transmitted on the appropriate channel (s). 

25 Decision block 340 determines if the channel is 

a one-way medium (e.g., pager, fax). if so, the 
customer's Push transaction is recorded in that channel 
and the process ends in block 345. m this case, the 
Push consists of "content" only and has no associated 

30 applet. These Pushes ask the customer to reply to a "1- 

800-" customer service center with a Push Code. The 
customer service center automatically signals the PAFCC 
64 that a valid response has been made to that Push. If 
the customer does not respond to the Push within a 
35 previously agreed time, the information is re- 
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transmitted. Retransmission stops when the Push goes 
stale. 

in block 350, the system waits for responses 
from the Push Dock. Possible normal responses are, in 
expected order: !, the Push Dock acknowledges a Push as 
recexved and valid; 2) the Push Dock acknowledges that 
the customer has received message; and 3, the Push Dock 
transmits customer response. Possible error messages 
are: I) the Push failed message authentication; 2) the 
10 Push Dock is full and can accept no more Pushes; and 3) 

the Push Dock is full and has replaced this Push with one 

receaved because a new Push" had higher priority. 

Decision block 355 decides if. an acknowledgment 
is received from the Push Dock, and if the acknowledgment 
15 s valid, invalid or indicates an error condition. Z 

TnTr T' T ° n ^ reSP ° nSe C °^ion determined 
in block 355, the response is accepted or the Push is re- 
transmitted or an error is logged. 
20 of Vision block 365 determines if other channels 

of transmission can be used, m the case where no valid 
response can be obtained from a channel and the customer 
has indicated more than one channel option and has 
requested being pushed channel by channel in serial 
order, the system checks if another channel is available 
for the customer. Pushing i» serial order means first 
trying Channel 1, then Channel 2, etc. Broadcast Push 
sends out the Push on all available Channels 
substantially simultaneously. if there other channel 
" options, then the process beginning at step 330 is 
repeated. in the case where no valid response can be 
obtained from a channel and there isn't another channel 
available and the Push becomes stale, then the Push is 
discontinued in block 370 and recorded as a failure. 

. In bl ° pk 375 ' a message is sent to the PAF 

Administration Component 66 (Figure 6A) alerting of the 
failed Push and the process ends in block 395 
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In block 380, if the Push Response is accepted 
then the Push was successful and the Pushes on other 
channels are terminated in block 382. 

In decision block 385, if the Push did not 
require a customer response, then the process ends in 
block 395. Otherwise, the Response is handed back to the 
PAFDC 62 (Figure 6B) for formatting as a standard bank 
transaction in block 390. The PAFDC 62 then enters the 
transaction into the standard Bank input stream. 

Various scenarios for use-cases are possible 
and envisioned for the system of the present invention. 
The table below summarizes these scenarios and indicates 
the drawing corresponding thereto. 







Figure Number 


15 


Customer Receives a Push for Personal 
Computer or a PDA device 


Figure 13A 




Customer Receives a Push for On-line or 
dial-in Terminal or a Smartphone 


Figure 13B 


20 


Customer Receives a Push for a 
Programmable Pager device, an 
Interactive Cable TV or interactive 
satellite cable TV 


Figure 13 C 




Customer Receives a Push via Telephone, 
Fax, Pager, One-way Cable TV, or One- 
way Satellite Cable TV 


Figure 13D 



Figure 13A details the receipt of a Push and 
the process of responding to it for a Personal Computer 
or a Personal Digital Assistant (PDA). In this scenario, 
the Personal Computer can be either a desktop 
or laptop computer. Assumptions for this scenario are as 
follows: communication is via Modem or similar device 
which is active; the protocol is TCP/IP; multiple 
responses can be processed at one time (for some PDA's, 
only one response can be processed) ; only one channel is 
available (e.g., Internet); dynamically assigned IP 
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15 



for an inactive connection and a statically assigned IP 
for an active connection; and if an error occurs during 
this process, the information is resent until either the 
bank stops, the transmission or transmission is successful 

In block 400 of Figure 13A, the Push Dock 
program, which was previously installed on the customer's 
Personal computer or PDA and runs, in the background, 
monitors the channel for incoming information. if the 
program detects a Push, then the process proceeds to 
block 405, otherwise it keeps monitoring the channel. A 
Push is identified by the proper header. For example, 
_ the system could detect an incoming Push by monitoring' " " 
incoming e-mails for the proper combination - of a return 
e-mail address and Subject. 

In decision block 410, the program and the 
incoming Push mutually validate each other as per the 
ANSI security standards. if there is no validation of 
security of the Push, the invalid Push and the 
corresponding error code is sent back to the bank for 
processing in block 415. 

Once the Push and Dock are determined to be 
valid (i.e. mutually authenticate one another), they are 
bound in block 420 (i.e., combined to form the message 
and the active process) . Binding the Push and Dock adds 
another level of security to the present invention, since 
it requires both a valid Channel and Dock. 

In block 425, the customer is alerted- to the 
Push and decides if he/she wants to view or ignore the 
Push in decision block 43 0. 

30 . If cust o*er elects to view the Push, the 

customer authentication process is initiated in decision 
block 43 5, requiring the customer to enter a pin or 
password. If this process is successful, a "Customer 
Received" acknowledgment is sent back to the bank in 

35 block 440. If the customer fails after three attempts to 

enter the correct password, then a. "1-800-- customer 
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service number, or the like, the Push's serial number and 
a message informing of a possible security breach are 
displayed. The Push Dock disables itself and destroys 
any local confidential data. All that remains of the 
5 Dock is. a repeat warning at each subsequent system 

startup of. the possible security breach. 

After processing the Push in blocks 436 and 
438, the customer 'chooses a Push Response which is 
.transmitted by the joined Push and Dock programs back to 
10 the bank in block 440. 

■ in decision block 445, if the. Response by the 
customer was not received or is incorrect (negative 
acknowledgment from the bank's server), the system 
attempts to retransmit the Response in block 450. 
15 •• k 1 If the Response transmission is unsuccessful, 

then the Dock displays a message to the customer in block 
455, including information about alternative methods of 
responding (e.g. 1-800 like response option) . The 
Response is then temporarily stored for later 
20 transmission in block 460. 

Once the correct Response Acknowledgment is 
received from the bank, it is displayed to the customer 
in block 465. in block 470, the Push is deleted from the 
customer Dock. 

The process depicted in Figure 13B details the 
receipt of a Push and the process of responding to it for 
an on-line or dial-in terminal or a SmartPhone. 

Assumptions for this scenario are: customer's 
online terminal is on a secure network; for a dial-in 
terminal, the customer must dial-in through modem or 
similar device to connect to system and it is assumed 
connection is not secure; for a smartphone, the system 
calls the customer; if encrypted, the connection is 
secure, otherwise it is not; the protocol for an online 
35 terminal is SNA or any terminal emulation supported 

. protocol for a dial-in terminal; for a dial-in terminal 
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the protocol is TCP/IP; only one response can be 
processed at a time; only one channel is available; 
statically assigned IP for an online terminal, 
dynamically assigned for a dial-in terminal; no 
5 persistent storage; the terminal may support Java 

applications; and if an error occurs during this process, 
the information is resent until either tlie Bank stops the 
transmission or transmission is successful. 

In block 500 of Figurei 13 B, a Push is received 
10 over the channel. If the terminal supports a Java 

Virtual Machine), then a Java application or applet, or 
the like such as Active components, is downloaded in 
block 505 which displays the Push information, as well as 
processing the customer's responses. ' 
15 If the terminal does hot support a JVM, then in 

block 510, only the information is displayed and all 
processing is done at the server. 

In block 515, the Push information is displayed 
to the customer. Message authenticity and client/server 
20 mutual authentication are delivered through the 

underlying security protocols. For a dial-in terminal 
session, Financial Industry and ANSI Secure Sign On 
standards are operational during the session. For some 
channels and/ or Docks certain transactions may require 
25 agreement ' from the customer, or may not be available for 

security reasons. 

In block 520, the customer decides to respond 
to the Push and appropriate responses are displayed. 

In block 525, the response and appropriate 
30 security codes are then sent to the bank. (Security in 

this situation can be established by the use of a one- 
time password of challenge response password device token 
in the possession of the customer) . The response from 
the customer is then processed on the bank's server and 
35 an acknowledgment from the server is sent to the 

customer. 



52 



BNSDOCID: <WO_9930295A1 J_> 



WO 99/30295 PCT/US98/25154 



In decision block 53 0, it is determined if the 
appropriate confirmation message was received from the 
server, A confirmation message is then displayed in 
block 535, if no problems were found. The original Push 
5 information is then deleted. 

. If . an error was generated, then an error 
message is displayed in block 540. The original Push 
information is then deleted* 

Figure 13 C details the receipt of a Push and 
10 the process of responding to it for a two-way pager, an 

interactive cable TV set top or an interactive satellite 
TV, Assumptions for this scenario are: the bank pages 
the customer; the connection may either be encrypted or 
non-encrypted; if encrypted the connection is secure; if 
15 non-encrypted, the connection is not secure; the only 

difference between encrypted and non-encrypted 
transmissions is th^ content that is transmitted; only 
one response can be processed at a time; only one channel 
is available; no persistent storage; and if an error 
20 occurs during this process, the information is resent 

until either the bank stops the transmission or 
transmission is successful. 

In block 550 of Figure 13C, a Push is received 
over the channel. The Push information is displayed to 
25 the customer in block 555. The Push is assumed to be 

valid. 

The customer responds to the Push in block 560, 
and the appropriate responses are displayed. 

In block 565, the response and appropriate 
30 acknowledgment codes are sent to the bank or to a paging 

company which routes it back to the bank. The response 
is then processed by the bank's server and an 
acknowledgment from the , server is sent back to the 
customer . 

35 In decision block 570, the confirmation from 

the bank's server is evaluated. If no problems are 
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found, a confirmation message is displayed in block 580. 
The Push is then deleted from the customer's device. 

If an error was generated, then an error 
message is displayed in block 580. The original channel 
5 information is then deleted from memory or cache. 

A programmable two-way pager, a programmable 
interactive CATV set top or a programmable; interactive 
satellite TV set top can all follow the PDA model 
described with respect to Figure 13A, provided that they 
10 have sufficient storage and functionality. Furthermore, 

a programmable interactive CATV Set Top can follow the 

PDA model, provided- it has suff icient storage arid " " 

functionality. .. 

Figure 13 D illustrates the receipt of a Push 
and the process of responding to it for several non- ' 
programmable devices such as a phone, a fax, a one-way 
pager, a one-way cable TV or a one way satellite TV. 

The assumptions, for this process are: the bank 
contacts the customer; channels are land-base or cellular 
phone, fax, pager, one-way interactive cable TV, or one- 
way interactive satellite cable TV; the customer only has 
the option of contacting the bank in response to the 
Push; and, depending on the customer profile, the 
customer is continually pushed until he/she responds 
25 In block 600, a Push is received over one or 

all of the above channels. 

The customer is informed. in block 605 to 
contact the Push Banking department. 

The customer then calls Push Banking in block 
610 Once Push Banking has been reached, no further 
transmissions are sent. 

A programmable device or one with encryption 
capability may allow for more detailed Push. message 
content. 

Figures 14A-14H illustrate several examples of 
"screen shots" of the various screens as seen by the 



20 



30 



35 



54 



BNSOOCID: <WO_9930295A1J_» 



' f^WO 99/30295 PCT/US98/25154 



customer on its devices and as seen by the screen 
monitoring the PAF Administration Components 66 (Figure 
6A) . 

Figure 14A depicts the delivery of an alert 
5 message to a customer using a personal computer. The 

message indicates to the customer that a Push has been 
received from the bank. 

Figure 14B depicts a screen on a customer's PC 
which displays all of the available push messages. The 
10 customer will subsequently be provided the appropriate 

functionality to complete the transaction. 

Figure 14C shows the screen of a customer's two 
way pager. The pager is displaying a message from the 
bank. Again, the customer will subsequently be provided 
15 , with the appropriate facility to respond to the push. 

Figure 14D is an illustration of a customer 
information screen as displayed by the PAF Administration 
Component 66 (see Figure 6A) at the bank's facility. 
This particular screen, and subsequent screens, are used 
20 to capture a customer's profile. (See Figure 12). 

Figure 14E is a PAF Administration Component 66 screen 
which displays details concerning a particular customer. 
Similarly, Figure 14F depicts various account information 
concerning a customer/ while Figure 14G displays a 
25 customer non-financial channel profile. 

Figure 14H illustrates a message from the bank 
being displayed on a U.S. Robotics Palm Pilot. After 
receiving the message, the customer will have the ability 
to respond to the message. 
30 This following section discloses some of the 

real world business situations which benefit from the 
present invention. Each of the examples below can use the 
notification and response processes described with 
respect to Figures 13A-13D. 

35 Example 1. Early Advising on Trade Fails 
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The trade purchase and settlement business 
process^entails a number of steps done alternately by the 
buyer, the seller,, and their respective intermediaries. 
The final step m the process : is the receipt of the trade 
5 on the settlement date by the custodian. The process has 

been automated and standardized across most major 
markets. However, the sheer volume and complexity of 
trade processing steps results in the failure of a 
percentage of trades, a trade fail is costly to all 

thfb e V nV ° 1Ved ^ ^ - --stment manager, 

, the broker and the custodian. When there is no fault In 

" I** faile * tradS ' com P-sation for the days lost may make 

the investment manager "whole" on an asset basis, but it 

15 a tradT ^h'" ^ effort to reconstruct 

J-s a trade or the. opportunity cost loss. 

Today, a custodian acts as an information and 
ultimately a value repository. They are paid to accept, 
transmit and store information about trades. With 

20 H° tradS SettlSment ' the ~ responsibility entails 

the matching of all of the specifications of the 

investment manager's trade with the broker. Multiple 
data fields are required: 1) a CUSIP number; 2) 
description; 3), currency; 4) rate; 5) counterparty; 6) 

25 "T?*** date ' S ° °"- T ° day ' S a »*°»ated systems 

25 wxii "fail-, a trade that does not have a perfect match 

between information about the trade from the investment 
manager and the information provided by the broker 
Failed trades are not reported until the end of 

settlement date, after which *-h~>-« • 
30 „ K . wmch there is no opportunity for 

the investment manager to change the outcome. 

Using the present invention, each investment 
manager could set up a profile, by type of security, of 
essential match characteristics. if these fields match 
with respect to a particular trade, and other less 
essential fields did not match, the custodian would 
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notify the investment manager that a trade would 
potentially fail. 

The relevant information about the unmatched 
trade w:ould bejforwarded to the investment manager. This 
5 would give the„ investment manager the opportunity to 

contact the broker to clarify the discrepancy and resolve 
the fail prior , to close of business on the settlement 
day. . . 

, All parties to the trade transaction would 
10 benefit from the early remedy approach. The custodian, 

the investment manager, and the broker would avoid 
handling an exception case. 

Example 2 - Credit Card Risk Advising 

Today, Credit Card Issuers bear the majority of 
the risk of lost and fraudulently used credit cards. 
Consumers are not liable for unauthorized transactions 
over $50, and merchants are not liable unless they fail 
to use online authorization systems. 

In order to reduce their exposure, many Credit 
Card Issuers have instituted notification and "stop" 
procedures. The notification procedure can be helpful to 
the consumer, but frequently it is implemented in a way 
that is embarrassing, not useful, or in some instances, 
actually damaging to the consumer; As a result, there 
25 can be a net negative result on the overall customer 

relationship. In a highly competitive market, this is 
not a desirable outcome. 

In a system employing the present invention, 
customers could proactively establish notification 
relationships with the Credit Card Issuer based on a more 
specific AI type of assessment. The most frequent 
unwanted notification situation arises when consumers 
travel on a vacation. This takes them out of their 
normal geographic spending area and also can increase the 
35 frequency of card usage. To remedy this, customers could 
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be offered a "VACATION PROTECT" service. The customer 
would notify the Credit Card Issuer of their travel 
plans, and essentially block these locales from the early 
warning procedure. 
5 Second, Credit Card Issuers could offer 

expanded notification services. . Today, they typically 
leave voice mail messages on the home phone of customers. 
To travelers, this is not helpful. A broader array of 
notification media could remedy this lack of service. 
10 Finally, customers would be allowed to notify 

the Credit Card Issuers in advance, presumably through an 

. itinerary, of _ certain planned shopping -excursions. - The 

customer could choose "Back to School" shopping spree, 
-Holiday" shopping spree, etc. in this way, a customer 
15 could be protected from embarrassing and time wasting 

interruptions at the shopping center. 

With these proactive capabilities in place, the 
Credit Card Issuer could retain their other fraud 
protection alerts and activities, since these protections 
20 would have a higher probability of signaling detrimental 

card activity. 

Example 3 - Credit Overrides 

Banks maintain credit facilities for 
corporations and financial institutions. In general, 
25 numerous transactions flow through the bank's clients' 

accounts during the day. Although the bank would prefer 
that all credits would arrive during the earlier part of 
tr.« day, and debits would be executed during the later 
p3rt of the day, this isn't how the real world works. 

30 wm* the bank tries to do is to essentially control the 

flow of funds. The bank executes as many payments as 
possible within the allowable intraday and overdraft 
?»cilities. As the end of day approaches, and debits are 
r.e ld up and credits aren;t in the bank, it. becomes 

35 imperative for the bank to contact its customers. Today 
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the bank calls its customers. This occurs either through 
the sales force or the client executive. Hopefully, the 
bank reaches the customer, and depending on the 
circumstances, the customer wires additional funds or 
5 advises the bank of other transactions that are in the 

process of being executed. Sometimes, the Bank can't 
reach the customer and payments aren't executed. 

The present invention allows the bank to go on 
a relentless search of the customer. First to contact 
10 it, then to receive a reply. Push Banking creates new 

improved methods of fluids control and cost savings. 

Example 4 - Fraud Control 

Checks that have suspicious signatures are 
called into a client's bank for approval. The window for 

15 acceptance of the signature is quite short. If a 

customer can be contacted with information or even an 
image of the check, the issue may be resolved 
immediately. The present invention allows such immediate 
contact and response. A certified authorization to pay 

20 the check may or may not be issued by the customer once 

contacted . 

Example 5 - Controlled Disbursement 

Today, a bank advises its customers via phone 
and PC of the amount of money they need to fund their 
25 controlled disbursement account. Many times the calls go 

unanswered and the funds notifications do not occur. 
Using the present invention, various methods as described 
herein can be activated until the bank reaches the 
customer and notification occurs, 

30 Example 6 - Unanticipated Deposits 

Occasionally large deposits arrive late in the 
day. If customers are fortunate and happen to be logged 
onto one of the bank's same day facilities they will be 
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able to invest the funds in the overnight market. More 
likely, the customer will not be able to execute the 
transaction. 

••> Usin 9 the present invention, the bank is able 
to notify and receive instructions from the customer and 
invest the funds per customer's instructions. 

Example 7 - FX Decisions 

Bank customers may want to wait for a FX rate 
before executing an FX transaction. The customer creates 
the transaction on the : bank's FX system and puts in a 

_. _.. wait-, order- for a rate-; — — - - - - 

Bv using the present invention, the customer 
would get notif ied of the rate and be able to send an 
instruction to execute the transaction with the preferred 
15 rate the customer has selected. 

Example 8 - Advising (including Advise to Receive) 

Sometimes a customer receives significant value 
into its account, either in one large receipt, or from 
the accumulation of several credits, perhaps 
unexpectedly. The customer may wish to do something with 
the funds, including investing, paying down a debt or 
paying off a vendor. 

, A second case could include the receipt of a 

credit that might also mean that a major collection 
25 concern is now completed, and the customer can focus on 

.- other, things (or call off litigation, or inform/thank his 
counterparty that the funds have been 'received) . 

The present invention enables each customer to 
establish a global profile (covering all accounts, world- 
30 wide). The profile can include a size-driven threshold 

for customer notifications and can in concept bridge 
accounts, even banking domiciles. One record per 
customer (or account) can be established for the 
notification of large single credits or cumulative 
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credits which can have value information and keywords 
about the remitter and/ or the remittance. The customer 
can enter an exact amount or a value range, and provide 
some key words to look for. These records would last for 
a set period of time, perhaps established by the customer 
w^en he sets up the keywords. Keywords can be added 
using the bank's existing cash management electronic 
banking system. 

These records could be part of the advising 
process, which resides on the back end of the real time 
posting system. Each of the advising systems around the 
world would, as part of the advising process, determine 
if the customer was set up for special handling (i.e., an 
a(i ^ ice V' in which case, the appropriate message would get 
sent by the Push Banking engine of the present invention. 



Example 9 - Changes in Market Conditions 

Some bank customers are exposed in currencies 
and countries to changes in market conditions, e.g. 
rapidly evolving conditions in Asia. The bank using a 
global balance monitoring system, which tracks on a real 
time basis, positions by currency and domicile. As 
changes occur in market conditions in a country or 
currency, customers with significant exposure could have 
their positions become at risk. The only issue really is 
what constitutes the appropriate conditions (such as 
civil war, a terrorist attack,* market fluctuations, etc.) 

In the present invention, customer profiles are 
created as part of the Push Banking System. Each time a 
major event happened, the news service (including 
currency movements) would feed the Push Banking System, 
which would seek out customers with country/ currency 
exposure above levels indicated in their profile 
(established by each customer, either at an account 
level, or across accounts) . A message would be sent by 
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the "Push Banking" engine advising the customer of the 
situation/ exposure . 

Example 10 - Corporate Actions 

Corporate customers as well as Private Banking 
5 customers hold investment positions that may require 

attention from time to time* The most significant event 
is response to a tender offer to buy, convert debt into 
equity or merge. There are other events of lesser import 
such as the annual proxy statement. 
10 Custodians that fail to notify their customers 

of_ these .events .subject ^themselves- to- legal liability, 

particularly if an opportunity is' "first-come, first- 
serve" (e.g. tender for a portion of the outstanding 
shares) * 

15 This could be extended to reflect significant 

movement in the value of positions on a percentage basis 
(but the movement must be greater than a minimum value, 
say two points, otherwise every fluctuation would 
generate excessive customer notifications) . 
20 In operation of the present invention, each 

time a news event hits, or each time the stock moves 
significantly a certain percent, the positions data base 
will be searched, and affected customers identified. The 
Push Banking engine of the present invention would search 
25 for the customer profile, and trigger the appropriate 

message to sent to the customer for his/her action. 

The Push Active Filter Decision Component 62 is 
responsible for processing information relating to all 
clients which are part of the PAF30 system. The 
3 0 processing covers all accounts for those clients, as well 

as other information of importance to the client that 
becomes known to the PAFDC 62. The PAFDC 62 must 
assimilate this information and send appropriate messages 
to the client via the PAFCC 64. In the event that there 
35 are too many clients for one physical processor, the list 
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of clients may be split into as many lists as necessary 
to reach a list size tliat a processor can cycle through 
in the time compatible with a promised level of service. 
Each list would then be processed by its own processor, 
5 If processors of different capabilities are to be used, 

the lists can be sized accordingly, since the system 
places no requirement for uniform size. The clients in 
separate lists must not require any consideration of 
interrelationships. When there is a requirement for 

10 considering interrelationships between clients, the 

interrelated clients are treated as an independent group 
appearing in one of the lists. The PAFDC 62 process is 
organized as shown schematically in Fig 15. 

The following section, describing the 

15 flowcharts in Figs. 15-21, relates to an example of the 

PAFDC 62. 

As shown in Fig. 15, the main task XYZDC 700 of 
the PAFDC 62 has four subtasks: Initialization 702, 
GetData 704, DecideAction 716, and SendData 718. 

20 Initialization 702 runs prior to each scan of all clients 

assigned to the PAFDC 62. The other three subtasks are 
contained in a loop that cycles through once for each 
client or related group of clients. The subtasks GetData 
704 and SendData 718 have their subtasks shown in Fig 15. 

25 The main task 700 of the PAFDC 62 is expanded 

in Figure 16 illustrating the flow of actions in the 
preferred embodiment. 

Start 73 0 is a label indicating the beginning 
point of the process which flows from there to procedure 

3 0 SetStart 732. SetStart initializes variables that must be 

set when the process first starts. In particular, start 
flags are set that are reset by processes that need to be 
informed when the first pass is made. MainLoop 734 is a 
label used by the process for reentry on looping after 

35 completely processing all the clients to repeat all the 

processing. Done 736 is the normal outcome path of task 
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Initialize 702. Loop 738 is a label used by the process 
for reentry on looping for each client or client group. 
Task GetData 704 obtains all, the data on a client or 
client group needed- to decide if a notification is 
,5 required* 

Done 740 is the normal outcome path of the task 
704, however if the end of file is : encountered, the path 
End of File 739 is followed going to the MainLoop 734 j; 
jump directive that brings the flow back to label 
10 MainLoop 734. Normal flow from Done .740 proceeds to task 

DecideAction 716 which examines . all the data for the 

client and determines if a message should be _sent and 

what the message content should be. If no notice is 
required, the flow proceeds via outcome No Action 742 to 
15 jump directive Skip 744, which brings the flow to Skip 

7503 label. If a message has to be sent to the PAFCC 64 
(Figure 6C) for conveyance to the client or* as a special 
instruction to the PAFCC 64, or . a transaction has to be 
initiated, flow proceeds via outcome Action 746 to task 
20 SendData 718 .. SendData 718 transmits the" message, if any, 

to the PAFCC 64, initiates a transaction if needed, and 
stores the activity in a historical file. Flow then 
continues from outcome Done 748 to label Skip 750 from 
which a decision is made on variable End 752 to direct 
25 flow via value, no 7.54 to procedure Incremental 756 or via 

value yes 762 to MainLoop 760; jump directive that brings 
the flow back to label MainLoop 734,. the latter path 
signifying the completion of processing of the client 
list and time to repeat the process, forming an endless 
.30. loop. Increment_I 756 adds one ; to the value of variable I 

k that serves as the index for accessing client data in the 

.client list. Flow then proceeds via Loop 758 jump 
directive that brings the flow back to label Loop 738 to 
process the next client in the list. 
351. The flow of processing in task Initialize 702 

is shown in Figure 17. 
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Processing in this task sets the default starting 
values for the client loop processing that begins with 
label Loop .738 (see Fig. 16) . The task also enables 
operating personnel to interpose process modifications if 
5 desired. Procedure InitSystem 770 sets the default values 

for processing. FileSelect 772 is a process that provides 
a graphical interface computer display to the operating 
personnel, enabling them to alter the processing if 
desired. The process modifies the default values, if 
10 changed by the personnel, but does not interrupt the 

processing unless directed by the personnel. Procedure 
JnitSystem2 774 then uses these default values to 
initialize all variables to begin the client processing 
loop. Flow then passes to outcome Done 736 of task 
15 Initialize 702. 

The flow of processing in task GetData 704 is 
shown in Figure 18. Task GetData 704 performs the 
function of PAFDC Situation Monitor 68 described in 
connection with Fig. 6B. 
20 The GetData process 704 obtains external data that 

is generally applicable to all the clients prior to 
starting the list of clients and thereafter just obtains 
client specific data. As seen in Fig. 18, the process 
begins by checking the value of index variable I 776. 
25 Each time the client list processing loop is started, 

InitSystem2 774 (see Fig. 17) sets I to 1 and flow 
proceeds along value path = 1.0 778 to task 
ObtainMarketData 706. This task reads data from all 
sources external to the institution employing the PAFDC- 
0 PAFCC pair that may have an effect on the decisions to be 

made by the PAFDC 62 on all clients. Flow then proceeds 
via outcome Done 780 to label NextRecord 798 and then on 
to task ObtainSIP DB 708. Task ObtainSIP_DB 708 reads in 
all traditional data available internally in the 
5 institution on one client selected by the index variable 

I 776. Flow normally proceeds via outcome path Done 782 
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to taskobtainPAF_PREF_DB 710 which reads in the profile 
set up by the client (also selected by I) describing what 
accounts are to produce notifications, how those 
notifications are to be triggered (notification 
criteria), and any special notification instructions. 
Obta inPAF_PREP_DB 710 makes preliminary recommendat ions 
about -notifications. Flow then proceeds via outcome All 
values 784 to task ObtainTransactionData 712 which reads 
in responses to any transactions for the client initiated 
by the PAFDC 62 at an earlier time if any are pending for 
the client. Flow then proceeds via outcome Done 786 to 

„ tas_k ReceiyeResoonses 714 :«hich -reads in- any^responses 

received via the PAFCC 64 from the client or generated by 
the PAFCC 64 (the- PAFCC may send a response indicating it 
did. not receive a response within the allotted time and 
has cleaned the pending messages out of all channels) . 
Flow then proceeds via outcome All values 788 to outcome 
Done 740 of task GetData 704. If task ObtainSIP_DB 708 
reads an end of file indication then the abnormal outcome 
End of ■, File 790 path is followed to task GetData 704 
outcome End of File 739. 

If the value of index variable I 776 is not equal 
to l.o, then flow proceeds via path <> l.o 792 to a 
second check on the value of index I 776. If the value of 
index I is less than the NumberOf Records , a variable 
equal to the number of client records to process set by 
.Initsystem2 774, then the flow proceeds via path < 
NumberOfRecords 794 to jump directive NextRecord 796, 
which brings the flow to "the NextRecord 798 label. If the 
value of index I equals or exceeds the NumberOfRecords 
value, then the flow proceeds via path >= NumberOfRecords 
800 to procedure SetEnd 802. SetEnd 802 assigns variable 
End 752 (see Fig. 16) to yes. Flow then proceeds to jump 
directive NextRecord 804, which brings the flow to the 
35 NextRecord 798 label. 
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The flow of processing in task DecideAction 716 is 
expanded in Fig 19. Task Decide Action 716 performs the 
functions of the PAFDC Decision Maker 69 and the PAFDC 
Prioritizer 71 (see Fig. 6B) . 
5 This ta^k is responsible for taking into 

consideration all the current data obtained on a client 
in conjunction with the past actions taken. This is 
accomplished by breaking the decision process into steps. 
The first step is to examine the responses received, if 
10 any. FlagR 810 is set to a value of 1.0 by the 

ReceiveResponses 714 task if a response is received for 
the client.. If FlagR is not equal to 810 the process flow 
follows path <> 1.0 812 to jump directive Skip 814, which 
brings the flow to the Skip 816 label. If FlagR 810 
15 equals 1.0 the process flow follows path =1.0 818 to 

task ProcessResponses 820. ProcessResponses 820 provides 
any special processing needed to organize the response 
data for making decisions. Process flow then proceeds 
via outcome path All values 820 and label Skip 816 to 
20 task DecideRecommendation 822 . , DecideRecommendation 822 

reads in the prior actions still pending for the client 
and further processes the client data to improve on the 
preliminary recommendations made by ObtainPAF PREF DB 710 
(see Fig. 18) if needed. Process flow then proceeds via 
25 outcome path NoAction 824 to task outcome No Action 742 

(see Fig. 16) if no notification to the client or 
instruction to the PAFCC 64 is required in consideration 
of the market data, client profile, responses from the 
client or PAFCC 64, transaction responses, and pending 
30 prior actions. 

When task DecideRecommendation 822 finds there is 
information that must be considered, process flow 
proceeds via outcome path Action 826 to task 
CheckOldActions 828, which makes a .comprehensive 
assessment of all the data on the client for each account 
of the client for which data is present. 
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An example of a portion of the logic of task 
CheckOldActions 828 is shown in Figures 20a through 20c, 

Procedure CheckOldActionsP 900 in Fig. 20 
initializes variables for the decision loop of task 828. 
5 Process flow then proceeds to label Loop 902 and then to 

procedure IncrementCount 904 which loads the variable 
AccountType with the next account type to be processed 
for that client, loads the variables to be tested, and 
adds one to the loop counter Count 906 which is tested 

10 against the value of variable CountEnd. When Count . 

becomes greater than CountEnd, processing is complete and 
processing flow passes via path > CountEnd 908 to outcome 
£ 0r ^ e ^ 83 0 of task CheckdldActions 828." Otherwise 
processing flow passes via path <= CountEnd 910 to test 

15 variable AccountType 912. Processing then flows out. one 

of the paths provided by AccountType 912 such as 401 K 
914 or Savings 916 to a decision logic tree tailored to 
that type of account, a portion of which is shown for the 
401 K type. The other account types (e.g. Savings 916) 

20 have similar logic associates with them. 

. The first variable tested in the 4 01 K tree is 
OldTNLogic 918 which contains a code representing the 
type of transaction that had been previously initiated 
and for which the PAFDC 62 is expecting an acknowledgment 

25 (it should be noted that string values could be used 

instead of the numeric values shown, depending on the 
nature of the information) . In this example 0 represents 
no transaction had been initiated for which an 
acknowledgment is expected. If the value of OldTNLogic 

30 918 is 0, then processing flow passes via path = 0.0 920 

to test variable TANLogic 922 which represents the 
transaction acknowledgment. TANLogic 922 has a value of 
0 when no acknowledgment is received. If TANLogic 922 
has a 0 value processing flow proceeds via path = 0.0 924 
35 ' to test variable OldRNUogic 926 which contains a code 
representing the type of response that had been 
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previously received and for which the PAFDC 62 has not 
completed processing* In this example 0 represents no 
prior response is pending completion. If the value of 
OldRNLogic 926 is 0, then processing flow passes via path 
5 « 0.0 928 to test variable RNLogic 930 which represents a 

response just received* RNLogic has a value of 0 when no 
response has been received. If RNLogic has a 0 value 
processing flow proceeds via path = 0.0 932 on Fig. 20B, 
to test variable OldMNLogic 934 which contains a code 
10 representing the type of message that had been previously 

sent and for which the PAFDC 62 has not completed 
processing. 

In this example 0 represents no prior message is 
pending completion. If the value of OldMNLogic 934 is 0, 

,15 then processing flow passes via path - 0.0 936 to test 

variable MNLogic 938 which represents a message 
recommended to be sent. MNLogic 93 8 has a value of 0 
when no message is recommended. If MNLogic 938 has a 0 
value processing flow proceeds via path = 0.0 940 to jump 

20 directive Loop 942, which brings the flow to the Loop 902 

(see Fig. 20A) label to process the next account to be 
processed for the client. If MNLogic 938 has a non-zero 
value processing flow proceeds, via path <> 0.0 944 to 
procedure SendNewMessage 94 6 which places the recommended 

25 Des sage into a list of messages to be sent. Processing 

then proceeds to jump directive Loop 948, which brings 
the flow to the Loop 902 (see Fig. 20A) label to process 
the next account to be processed for the client. 

If the value of OldMNLogic 934 is not .0, then 

30 pressing flow passes vi a path <> 0.0 950 to test 

variable MNLogic 952. If MNLogic 952 has a 0 value 
processing flow proceeds via path = 0.0 954 to procedure 
cr.e cKTimeout 956 which determines if a response is 
overdue. The PAFCC 64 should clean up this message and 

35 send a response to the PAFDC 62 confirming its action, 

therefore if an excessive time has passed this procedure 

69 



BNSDOCID: <WO 9930295A1 i 



WO 99/30295 



PCT/US98/Si54 



places an instruction into the list of messages to be 
, sent to the PAFCC 64 to correct this error condition. 
Processing then proceeds to jump directive Loop 958, 
which brings the flow to the Loop 902 (see Fig. 20A) 
5 label to process the next account to be processed for the 

client. If MNLogic has a non-zero value processing flow 
proceeds via path <> 0.0 960 to test variable OldMNLogic 
962. If, OldMNLogic 962 equals the value of MNLogic 
processing, no new message has to be sent, therefore flow 
10 proceeds via path - MNLogic 964 to procedure CheckTimeout 

966 which has been described at 956. Processing then 
proceeds to jump directive Loop 968, which brings the 
flow to the Loop 902 (see Fig. 20A) label to process the 
.next account to be processed for the client. If 
15 > . OldMNLogic 962 does not equal the value of MlJLogic 
processing flow proceeds via path <> MNLogic 970 to 
procedure DecideNewMessage 972 which places the 
recommended message or a modified message into the list 
of messages to be sent, depending on the relationship of 
20 the new message to the old (For example the prior message 

may have advised that an account would be overdrawn if 
$1000 weren't immediately transferred to it. New 
information indicating that -now $2000 would have to be 
transferred into the account would produce a message to 
25 that effect. ). Processing then proceeds to jump directive 

Loop 974, which brings the flow to the Loop 902 (Fig. 
20A) label to process the next account to be processed 
for the client. 

If RNLogic 930 (see Fig. 20A) is not equal to 0, 
30 then a new response has been received (since OldRNLogic = 

0) , and processing flow proceeds via path <> 0.0 976 (see 
Fig. 20C) and. label NewResponse_NoTransaction 978 to test 
. . . variable OldMNLogic 980. 

If the value of OldMNLogic 98 0 is 0, we can 
35 conclude that this response is not related to a pending 

message, and processing flow passes via path =0.0 982 to 
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test: variable MNLogic 984. If MNLogic has a 0 value, no 
new notice message is recommended, so processing flow 
proceeds via path = 0.0 986 to procedure ClientRequest 
988. The procedure determines if the PAFCC 64 has 
5 generated the response, or the client has initiated a 

request and acts accordingly by initiating a transaction, 
message, • and/ or update of its state information. 
Processing then proceeds to jump directive Loop 990, 
which brings -the flow to the Loop 902 (see Fig. 20A) 

10 label to process the next account to be processed for the 

client. 'If MNLogic 984 has a non-zero value processing 
flow proceeds via path <> 0.0 992 to procedure 
ClientRequestAndNewMessage 994 which, in addition to 
performing actions similar to those done by ClientRequest 

15 988, must consider the new notice message content in 

formulating its action. Processing then proceeds to jump 
directive Loop 996, which brings the flow to the Loop 902 
(see Fig. 20A) label to process the next account to be 
processed for the client. 

20 If the value of OldMNLogic 980 is not 0, then 

processing flow passes via path <> 0.0 998 to test 
variable MNLogic 1000. If MNLogic 1000 has a 0 value 
processing flow proceeds via path = 0.0 1002 to procedure 
StartTransactionAndCheckTimeout 1004 which verifies that 

25 the response is timely and relates to the pending message 

that had been sent (OldMNLogic 980 <> 0) . Then depending 
on whether the response indicates a PAFCC 64 instruction, 
client initiated request, late response, or timely 
response to the message sent, the procedure provides the 

30 appropriate action, such as initiating the transaction 

solicited by the message sent. Processing then proceeds 
to jump directive Loop 1006, which brings the flow to the 
Loop 902 (see Fig. 2 OA) label to process the next account 
to be processed for the client. If MNLogic 1000 has a 

35 non-zero value processing flow proceeds via path <> 0.0 

1008 to test variable OldMNLogic 1010. Processing now 
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proceeds in similar manner as described above at 
OldMNLogic 962 (see Fig. 20B) only now taking into 
account the fact that a response has been received 
(RNLogic 930 <>0) . First it must be verified that the 
5 response doesn't indicate a PAFCC 64 instruction or 

client initiated request, Next if not a late response, 
then a transaction most likely should be initiated. 

In similar manner the paths for OldTNLogic 918 
(see Fig. 20A) , TANLogic 922 (see Fig. 20A) , and 
10 OldRNLogic 926 (see Fig. 20A) are processed for all 

possible combinations. Likewise, other account types such 
.._ i .__ :._ a f Savings 9 [l§-( see _Fig. 20A) . has. its ..own ...logic-tree f or— 
processing clients with actions appropriate to that type 
of account. When all accounts for a client have been 
15. individually processed without regard for interactions 

between accounts, processing exits task CheckOldActions 
8 28 via path Done 83 0 and proceeds to task 
CheckCommonality 832 on Fig. 19. CheckCommonality 832 
uses a similar tree structured logic to examine the 
20 interrelationships of multiple transactions, responses, 

and messages within and between accounts for the client 
if more than one are currently being processed. Where 
conflicts are discovered, they are resolved via 
predefined business rules and the transactions and 
25 nessages modified accordingly. 

Processing then proceeds via path Done 834 to task 
StoreActions 836 which places the results in non-volatile 
memory. Processing then proceeds via path Done 838 to 
outcome Action 746 (see Fig. 16) of task DecideAction 
3 0 7i6. When processing proceeds along path Action 746 to 

t^isK SendData 718, we go to Fig 21 to see the'steps 
w;thin that task. The task SendData 718 performs the 
function of the PAFDC Push Package 70 described with 
..respect to Fig. 6B. 
35 Variable SendM 1020 is set true in task 

DecideAction 716 if a message is to be sent, otherwise it 
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is set to false. If SendM's value is false, processing 
proceeds via path false 1022 to jump directive SkipM 
1024, which brings the flow to the SkipM 1026 label. If 
SendM's 1020 value is true, processing proceeds via path 
5 true 1028 to task SendMessage 720 which queues up the 

messages to be sent to the PAFCC 64. Processing then 
proceeds via path All values 1030 and label SkipM 1026 to 
test the value- of variable SendT 1032 whose value is also 
set in task DecideAction 716. If no transactions are to 
10 be initiated, SendT will be false and processing proceeds 

via path false 1034 to jump directive SkipT 103 6, which 
brings the flow to the SkipT 1038 label. If SendT's value 
is true, processing proceeds via path true 1040 to task 
SendTransaction 722 which initiates the transactions 
15 determined by DecideAction 716 . Processing then proceeds 

via path All values 1042 and label SkipT 1038 to task 
UpdateActionHistory 724 which stores all actions taken in 
non-volatile memory. Standard transaction processing ( as 
known in the art) is used throughout, so that if any 
20 processing can not be completed, the process is rolled 

back so that an accurate record of the current state is 
always known. Processing then proceeds via path All 
values 1044 to outcome Done 748 (see Fig. 16) of task 
SendData 718. 

25 Although the preferred embodiment as described 

uses scanning of the list of subscribers at prescribed 
intervals, it is appreciated that asynchronous event 
triggering and asynchronous scanning of subscribing 
clients is equally included within this invention. 

30 Likewise the separation of deciding on each account 

separately for notifications and then reviewing those 
notifications collectively to remove conflicts, 
ambiguity, or any other nuance that produces a less than 
desired effect, rather than combining these operations 

35 does not limit the scope of this invention. Sending all 

notifications generated up to the time of ah interrupting 
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immediate notice requirement is also just a variation on 
implementation. It is within the scope of the invention 
to send just the interrupting notice with or without any 
generated notices for that client, and then continue the 
5 normal processing. • . 

Communications Components, decision making 
components and caches are applicable at many points in 
the overall PAF 30 system/ Combining these discrete 
functional units into component-like units may provide 
10 some benefits. This section discusses and expands upon 

this concept* 

1 Fi ? u _ re .: 22 ' _? ?°j™uni^ 

Making & Caching Component 1100, or CDMC. A CDMC 1100 is 
composed of a logical decision component "1102 surrounded 
15 by communications handlers 1104, 1106/ and caches 1108. 

The logical decision making component "11*02 is 
divided into a Sending Decision Maker 1110 (S-DM) and a 
Receiving Decision Maker 1112 (R-DM) . The S-DM 1110 is 
responsible for sending data to other CDMCs 1100 and the 
R-DM 1112 is responsible for receiving data from other 
CDMCs 1100. ("Data" is used loosely here to encompass 
business data as well as updates to information used by 
CDMC ' s 1100 upon which they make decisions, and various 
kinds of profile information) . 
25 A decision making component - S-DM 1110 or R-DM 

H12 - is intended to make decisions appropriate to its 
context in the "CDMC network" and may rely on a variety 
of technical implementations to make these decisions. 
For example, an S-DM 1110 might use a database trigger 
30 and embedded SQL logic and/or external rules contained in 

another database to determine if "interesting" data has 
been updated, inserted or deleted from the database it 
monitors. R-DM's 1112 might be responsible for 
distributing updates to databases based on destination. 
35 An S-DM 1110 responsible for deciding over what channel 

to send an Push would read customer profiles. An S-DM 
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1110 responsible for evaluating and reconciling customer 
interest profiles and potentially Pushable data might 
employ an Al engine. 

Caches 1108 axe provided for caching of items 
5 intended to be sent in either direction. (Caches 1108 

are depicted in Figures 22 as associated with 
communications components in order to illustrate that l) 
they need not be physically attached to the CDMC 1100 as 
well as 2) they need not be totally external to the CDMC 
10 1100) . 

CDMCs 1100 are intended to be connected by various 
means. For example, CDMCs 1100 can be connected to each 
other on an internal network, to data sources such as 1) 
databases via native database APIs, ODBC, JDBC, etc., or 
15 2) news feeds via dial-up or whatever method supported by 

the feed, to network file systems for file access, etc. 

By defining context and responsibilities for 
CDMCsllOO and connecting them using appropriate channels, 
a "network 1200" of CDMCs 1100 might result, as depicted 
20 in Fig. 23. 

The following is a brief example narrative of how 
messages are constructed, sent, responded to and acted 
upon in the CDMC network 12 00 as illustrated in Figure 
23. 

25 Three kinds of data sources are depicted in the 

column labeled Legacy Agents 1201, data extracted from 
line of business database 1202, direct . access to line of 
business database 1204 and a data feed 1206. In all of 
these cases, each D-CH 1104 provides the connectivity 

30 between the CDMC 1100 and the data source. For example, 

perhaps the data extract is a flat file located in the 
networked file system and is read line-by line and 
parsed; perhaps the directly-accessed database-base has 
1) a native API installed in its corresponding CDMCs 

35 1100 D-CH 1104 or 2) uses a database-based trigger to 
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detect updates; perhaps the data feed sends information 
to the CDMC 1100 via TCP/IP. 

I ' n -.*. 11 ' three cases, the S-DM 1110 in the CDMSc 
1100 are configured with data relevance filters 1208, 
perhaps an AI engine perhaps a full-text indexing system 
that counts the number of times specif ic phrases occur 
over a given period of time coupled with application 
logic to detect high occurrence and notify downstream 
processes. 

If a CDMC lioo becomes too busy to handle the 
incoming information, the Cache 1108 is employed to cache 

_ the data *_ ^}^^^Yf?-yL.'3-^^9.:^9'9j^^ld_diTBc^ 

another CDMC 1100 to handle part of its load, CDMCs 1100 
could: also conceivably serve as pure "routers" of data. 

Data that passes through the filters 1208 are sent 
through the sending U-CH 1106 onto the internal network 
1210. A Cache 1108 is also available here to cache data; 
data could also be routed as described in the previous 
paragraph. - 

The next three steps in the round-trip describe a 
potential way of breaking the problem into smaller steps 
that could be separately administered: 

Data Association 1212 could be a next step in the 
round-trip. Here, a CDMC nob is responsible for 
25 receiving data from the internal network 1210 and 

applying customer/data associations 1214-linking 
customers' preferences with the available data. The 
receiving D-CH 1104' serves to link' the CDMC 1100' onto 
the network 1210. The description of the roles of s-DMs 
1110' their data filters 1216, the caches 1108' and U-CH 
in the previous paragraph also apply here. 

In the PAFDC 1218 step, priorities are assigned to 
the data passed from the Data Association 1212 step. The 
receiving D-CH 1104" serves to link the CDMC 1100" onto 
35 the network 1210. Again, the description of the roles of 
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S-DMs, their data filters, the caches and U-CH in the 
Legacy Agents 1201 paragraph also apply here. - 

The PAFCC 1220 step decides over channel (s) to 
send customers ' Push message . Group and surrogate 
5 association could also be done here in CDMC 1100' " or in 

a previous and separate CDMC The outgoing U-CH could 
consist of one or many channel interfaces; additional 
CDMCs could also, implement specific channel interfaces. 

The Push message is sent to the customer (or to 
10 internal or carrier personnel as administrative alerts). 

The customer's device has an appropriately configured 
CDMC 1250 consisting minimally of the D-CH 1251 that 
provides incoming and outgoing connectivity and a 
decision component (e.g. the person receiving the Push 
15 : message) . If the device is sophisticated enough, an 

intelligent/ automated R-DM decision component 1254 could 
respond to messages; and additional U-CH 1256 could allow 
storing messages on devices other than the receiving 
device itself, caches could also be implemented for 
20 message storage. 

The customer responds to the Push message and his 
response returns to the system through his device's D-CH 
1252, and the designated channel, arriving at a CDMC 
configured as a PAFCC that accepts responses. (The 
25 customer could also phone a CSR. This CDMCs R-DM 

determines the nature of the message (for example, 
response to the Push message, profile update requested by 
a customer) and routes the data (through the CDMC network 
for a response or initiating the challenge-and-response 
30 message for profile rupdate requests) . Based on rules 

associated with the R-DMs along the chain, the response 
is ultimately sent to the CDMC responsible for effecting 
the transaction, being. cached and routed as necessary. 
Profile updates can also be sent along the CDMC network 
35 according to the type of update - customer channel 
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updates, group and surrogate information, customer/data 
relationships. 

The basic CDMC design could also be used to 
; provide message truncation, intended to truncate messages 
for transmission across overloaded channels. 

The following, section describes the information 
contained in a PAFCC 64 profile. It speaks of a dock 
address, meaning a name identifying a type of dock plus 
dock-specific addressing information. A string with the 
general format "Dockname/Addressirig-inf o« specifies a 
dock address. The following dock address strings are 
standardized here: 

Browser/aaa . bbb . ccc . ddd : ' describes the address for 
an Internet browser running on a PC - accessible at the 
15 given IP address. 

PalmPilot/aaa.bbb.ccc.ddd: describes the address 
for a PalmPilot with CDPD accessible at the given IP 
address. 

Skytel/nnnnnn: describes the address for a Skytel 
two-way pager with the given pin. 

NumPager/ccc-aaa-pppppppppp: describes the address 
for a numeric^only pager accessible at the given phone 
, number (ccc = country code; aaa=area code or city 

code;ppp P ppppp P = i ocal number; total length of c+a+p = 
25 18 digits maximum) 

The PAFCC 64 profile of a customer contains at 
least three fields: Docks, Send-Also, Send-On-Failure. 
Each contains one or more dock addresses. There is also 
an auxiliary field called Failure-Timeout. 

The Docks field. lists the dock addresses at which 
this customer can be reached. The PAFCC 64 uses these 
addresses first, sending the message in parallel to all 

The Send-Also field lists the dock addresses at 
which. someone other than the customer (spouse, secretary, 
lawyer, broker, etc.) can be reached. The PAFCC 64 
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transmits in parallel to these Send-Also dock addresses 
after Dock transmissions are complete or have failed. 

The Send-On-Failure field lists dock addresses to 
be tried in parallel if transmissions to the Dock or 
Send-Also dock addresses fail . Failure is defined as 
either hard failure as reported by the dock driver, or 
the absence of a useful response after Failure-Timeout 
seconds. Send-On-Failure dock addresses may be 
associated either with the customer (in which case they 
probably represent less desirable transmission paths) or 
with third parties. 

The following section describes one way that the 
PAFDC 62 and PAFCC 64 could exchange information and 
depends on the example XML specification detailed in the 
following section. In general, the two systems operate 
independently, queuing output to each other in files 
within a shared directory. This can be a local disk 
directory, if the two systems run on the same machine, or 
a shared network directory. The only assumption is that 
the operations of renaming and deleting files in the 
directory are atomic (uninterruptible) . 

In general, rendezvous is controlled by the PAFDC 
62, which decides when to release a queue of requests to 
the PAFCC 64 and accept a queue of responses. The PAFCC 
64 polls the shared directory to see whether a certain 
file exists. If so, it injects the contents of that file 
into its internals. in general, files named DC*. TXT are 
solely controlled by the PAFDC 62, and files named 
PAFCC*. TXT are solely controlled by the PAFCC 64. «*•» is 
the usual wildcard symbol, representing any characters 
whatsoever. The files UP. TXT and DOWN. TXT are shared 
between the two systems. 

The PAFDC process cycle: : Reads responses from the 
file DCRESP.TXT, as well as other sources of information, 
35 and write requests to the file DCREQ.TXT. 
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When the reading of DCRESP.TXT and the writing of 
DCREQ,txt are both complete, initiate a rendezvous as 
follows: Close and remove DCRESP.TXT. 
Close DCREQ.TXT. Rename DCREQ.TXT to DOWN. TXT. 
Wait until the file UP . TXT ■ exists . Rename UP. TXT to 
DCRESP.TXT. Re-open DCRESP.TXT and the new DCREQ.TXT. 
Continue looping. 

The PAFCC 64 process cycle includes: 
Poll continually for the file DOWN.TXT. if it 
exists, a rendezvous is required as follows: Rename 
DOWN.TXT to CCxxxxxxxx.TXT, where xxxxxxxx is a unique 

_1 V ^ 1Ue *... Th& . Simples \. ch ° i 5. e _i s _ a ? encoded date/ time. 

Serial numbers also work but are harder to make robust in 
the face of application crashes. Close CCRESP.TXT. 
15 Rename CCRESP.TXT to UP. TXT. Re-open new 

CCRESP.TXT. Continue processing. Otherwise, process 
requests in CCxxxxxxx.TXT files in priority order, and 
write all requests to CCRESP.TXT. Processing requests in 
priority order will involve merging requests from 
20 multiple CCxxxxxxx files, in general. 

All files must contain one or more complete XML 
documents, separated by one or more line breaks. This 
guarantees that the <PAF> tag always appears at the 
beginning of a line, and the </PAF> tag appears at the 
25 ,end of a .line. 

Multiple PAFDC/PAFCC pairs should use unique 
shared directories. in effect, this places the identity 
of the pair into the pathname of the directory. 

The following section provides one method for 
implementing a Message Dock on a 3Com PalmPilot using the 
general markup language XML (extensible Markup Language) . 
This section describes what a PalmPilot Dock would look 
like. 

The application will be downloaded to a customer's 
PalmPilot via the regular HotSync conduit for 
applications. When loaded on the system, it will monitor 
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the airwaves (via the CDPD modem) for a Push message 
transmission. When received, it will produce an audible 
signal but not display anything until the customer 
selects the application. (The application can be bound 
5 to one of the hardware buttons if the customer so 

chooses . ) 

When the application is visible on the PalmPilot 
screen, it will display the current message selected by 
the customer. If there is no currently selected message, 

10 it will display the highest priority message. The 

hardware UP and DOWN keys allow the customer to step 
through messages in order of priority: UP moves to the 
. message with next-highest priority, and DOWN to the 
message with next-lowest priority, relative to the 

15 currently displayed message. If the message is larger 

than the PalmPilot screen, a standard PalmPilot scrollbar 
will provide access to the portions not currently 
visible. 

By tapping on the message, the available responses 
20 will appear in a pop-up menu, along with two standard 

choices, "Other" and "Act By". Choosing one of the 
available responses will cause the application to connect 
to the PalmPilot dock driver (using the CDPD facility 
again) and transmit the response. The address of the 
25 dock driver will be saved from the last received message. 

Choosing "Other" allows the customer to enter a 
response either in Graffiti or using the virtual 
keyboard. When the response is composed, it can be sent 
cr deleted. 

30 Choosing "Act By" allows the customer to enter a 

ti»c (relative to the current time zone) by which the 
r»5;.onse must be acted on. Setting this does not send 
a r. ; - trying. The value is saved with the current message 
ar l is applied when a response is eventually sent. 

35 Tapping on a message that has already been 

responded to gives an error pop-up. 
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The following commands will be available in the 
application menu: 
Move: 

Up: same as UP key 
5 Down: same as DOWN key 

F ^ r st: the highest-priority message 
Last : the lowest-priority message 

View: 

Creation Date: shows the creation date of the 
10 current message 

Stale Date: 

shows the stale date of the ^current message 
^SettlngsT: - - - - - - 

Quiet: a checkable option to suppress the alarm 
15 ~ Features: pops up a Feature dialog box 

Purge: Remove messages that are past their stale 
dates or have been replied to by the 
customer. 

The Feature dialog box provides customer-friendly 
names for various entries in the customer's PAFCC 64 and 
PAFDC 62 profiles, and relevant options for setting them. 
Choosing OK from this dialog box causes a spontaneous 
upstream message to be sent from the PalmPilot to the 
dock driver. If ' the dock driver has not sent anything, 
wait for the next heartbeat transmission (see below) . 

- Heartbeat: The dockdriver will send a minimal 
message with just ID, TO, and CD elements occasionally 
(how often depends on system and network load). This 
will serve as an indication to the PalmPilot that the 
dock driver and the modem are still working, and will 
allows the PalmPilot to determine the difference between 
local time and universal time. This offset is always a 
multiple of 15 minutes, so subtracting the PalmPilot's 
idea of local time from the time given in the CD element, 
and then rounding to the nearest multiple of 15 minutes, 
will give a reliable indication of the offset. The 
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offset can then be added to universal dates to convert 
them to. local ones, or subtracted from local dates to 
convert them to universal ones. 

The PalmPilot application will use UDP/IP 
datagrams for communication with the dock driver. 
Exceptionally, heartbeat messages are not acknowledged, 
because if they are lost it makes little difference. 

. P M lmPi f 0t sec^ity follows the general principles 
of Internet Dock security. The PalmPilot dock driver 
encrypts and digitally signs all downstream messages 
using public-key technology before transmission. The 
messages are decrypted, and the signature verified, just 
before the message is to be displayed to the customer. 
Messages that cannot be decrypted or that fail signature 
verification cause an error message to be sent upstream 
and the customer to be notified. The PalmPilot database 
stores the messages only in encrypted form. 

In the same way, upstream messages, are encrypted 
and signed before transmission back to the PalmPilot dock 
20 driver, which then decrypts them and verifies the 

signature. 

In order to gain access to the private keys kept 
on the PalmPilot, the customer must provide. a PIN. This 
PIN is used to produce a secret key that encrypts and 
25 decrypts the private keys. Without the PIN, the secret 

keys are inaccessible, so possession of the PalmPilot 
without the PIN prevents downstream messages from being 
read (because they cannot be decrypted) and upstream 
messages from being created (because they cannot be 
30 authenticated) . Neither the PIN nor the corresponding 

secret key ever leaves the PalmPilot. 

The following XML Document Type Definition (DTD) 
describes the format of Push message PAF documents. PAF 
documents are intended to be parsed as if they contained 
35 the following declaration: 
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<!DOCTYPE PAF SYSTEM "paf .dtd«>, where paf .dtd has the 
following contents: 

<!— DTD Draft 1.0 for Push Message PAF documents 
<!-- These are the element types that can be found. 
<! ELEMENT PAF (ID, CD?, TO? , DA? , PR? , SD? , . MT? , RT?, 

AD?, RE? , ER? , CF?)> ' 
<!-- This means that ID is first and is required, and all 
the others are optional but MUST appear in the specified 
order. In particular uses, some of them are NOT 
optional: thus PAFDC 64, output must include. SD and MT, 
and dock drivers will be helpless if their input doesn't 
contain DA. - — > 
< ! ELEMENT ID (/PCDATA) >~ 

< I ELEMENT CD (/PCDATA) > - , : • . , 

15 <! ELEMENT TO (/PCDATA) > . . 

< I ELEMENT DA (/PCDATA) > 

<! ELEMENT PR (/PCDATA) > 

<: ELEMENT SD (/PCDATA) > 

<! ELEMENT RT (/PCDATA) > 
20 <? ! ELEMENT AD (/PCDATA) > 

<! ELEMENT RE (/PCDATA) > 

<! ELEMENT ER (/PCDATA) > 

<! ELEMENT CF (/PCDATA) > 

<!— All of these contain just characters, possibly with 
5 numerical references like &/nnn; and a few general 

references like < and > mixed in. There are lots of 
specific rules about their format, but XML can't cope 

those rules, and treats them as plain character 
Jita. — > 

3 « 'XI EMENT MT. (/PCDATA | RT) *> 

-- y.~? elements can contain text and any number of RT 
elements mixed together in any arbitrary way. > 
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<! — These are the attributes that elements can have. 
Elements that aren't mentioned here don't have any 
attributes > 

<! ATTLIST MT 

5 xmlrlang NMTOKEN #IMPLIED CODE NMTOKEN #REQUIRED> 

<! — MT elements have two attributes, xmlrlang (which is 
lowercase because the XML spec defines it) and CODE. 
Both are alphanumeric values, or NMTOKENs in XML jargon. 
If xml:lang is missing, an application-specific value is 
10 implied. 

If CODE is missing, it's an error. — > 

< i ATTLIST RT KEY NMTOKEN #IMPLIED> 

<! — RT elements have one attribute, KEY. It's an 
alphanumeric value (NMTOKEN) . If it's missing, an 
15 application-specific behavior results (namely, there is 

no key for this return value) . — > 

<i — Declarations needed for XML/ SGML compatibility. XML 
systems will work fine without these, but old SGML 
systems may not. — > 

20 <i ENTITY It "&#60;"> 

<! ENTITY gt ">"> 

<! ENTITY amp "&#38 ;#38 ; M > 

<! ENTITY apos "&#39;"> 

<! ENTITY guot """> 
25 The following is a description for the XML 

document type that describes Push message PAF documents, 

both PAFDC 62 handoffs and PAFCC 64 handoffs. It is also 

used by PAFCC 64 to communicate with the dock drivers for 

individual docks* Some dock drivers may also send this 
30 format to the docks themselves. Sample documents can be 

found at the end. 

The following general rules, apply to this 

discussion: 
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Line breaks may be freely inserted into any PAF 
document except between < and >; they have no 
significance* However, when a single file contains more 
than one. document, each document should be separated by 
5 one or more line breaks, so that each <PAF> tag is at the 

beginning of a line and each </PAF> tag is at the end of 
a line. > . * . . 

The structure of a PAF document consists of 
elements, which are represented by balanced pairs of 
10 start tags and corresponding end tags, with intervening 

content. 

Each start tag looks like <XX>; each end tag looks 
like </XX>. The XX' s must match exactly. Case matters 
throughout the document. 
15,. . . Some start tags have attributes, which appear 

between the XX and the >. Attributes are of the form 
name=value. The XX is separated from the first 
attribute, and attributes are separated from each other, 
by spaces. 

20 Content may be text or more elements or both, 

depending on the particular element in question. PAF 
elements contain only other elements, MT elements contain 
text and RT elements, and all other elements contain only 
text. 

25 Text consists of either printable ASCII characters 

(with the exception of &, <, and >) , which represent 
themselves; or entities, which begin with & and end with 
;. In PAF documents, the following entities are 
recognized: 

3 0 & an & character (does not signal an 

entity) 

< a < character (does not signal a tag) 
> a > character (does not signal a 

tag) &#nnnnn; a non-ASCII character, where nnnnn is 

35 the decimal representation (without leading zeros) of its 

Unicode/ISO 10646 value. Allowing any Unicode character 
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permits the message to be correctly represented 
regardless of its language. (Note: The Latin-1 
character sjet is a subset of the Unicode character set, 
so Latin-1 and Unicode character codes in the range 160- 

5 255 are the same.) 

The entire PAF document is a single PAF 
element. Therefore, the document begins with a <PAF> 
start tag and ends with a </PAF> end tag. All the other 
elements are contained within the PAF element. The MT 

0 element can contain RT elements as well as text: all 

other elements contain only text. 

Documents sent by the PAFDC 62 to the PAFCC 64 
and on to the. dock drivers are called downstream 
documents. Documents sent by the dock drivers back to 

5 the PAFCC 64 and on to the PAFDC 62 are called upstream 

' documents. Some elements are found only in downstream 
documents, some only in upstream documents, and some in 
both types. 
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Table 3 contains all the valid element types. 



Tag 


Attributes 


Source 


Content 


Format of text 


PAF 


None 


Ail 


All other 
elements in any 
order (see above) 


None 


ID 


None 


All 


Text: unique ID 
of document 


Alphanumeric 


CD 


None 


All 


Text: creation 
date of document 


ISO 8601 (see 1 
below) 


TO 


None 


Down: PAFDC 


Texfccustomer ID 
of recipient 


Alphanumeric 


DA 


None 


Down: PAFCC 


Text: dock- 
specific address, 
including the 
name of the dock 


Dock-specific 
(see 2 below) 


-PR . 


None _ 


Down: PAFDC. 


-Text:- priority of - 
document 
(0= minimum, 
1= maximum) 


-Decimal fraction 


SD 


None 


Down: PAFDC 


Text: stale-date 
of document 


ISO 8601 (see 1 
below) - 


MT 


xmlrlang (see 3 
below) 


Down: PAFDC 


Text: message 
being sent 


Free format 
plain text 




CODE fcee 4 
. below) 


RT plraipntc* 

suggested 

responses 






RT 


KEY (see 5 
below) 


Down: PAFDC 

Un; dock driver 


Text: response 
text 


Free format 

nlftSn t<*v# 

Ulffllll ICJhb 


AD 


None 


Up: dock driver 


Text: action date 
for response 


ISO 8601 (see 1 
below) 


RE 


None 


Down: PAFDC 
Up: dock driver 


Text: unique ID 
of another 
document to 
which this 
document refers 
(see 6 below) 


Alphanumeric 


ER 


None 


Up: PAFCC or 
dock 


Text: error 
message 


An empty 
content indicates 
"no error". 
Otherwise TBD. 


CF 


None 


Up: dock 


Text: request for 

configuration 

change 


Component 
Name = Value 
(see 7 below) 



Notes to tabled: 

The format of date elements conforms to ISO 

■ r ,8601, and is as follows: yyyymmddThhmmss, where yyyy 

represents the 4 -digit year, mm represents the month 

20 number from 1 to 12, dd represents the day number within 

88 



BNSDOCID: <WO 99Q0295A 1J_> 



^f^WO 99/30295 



PCI7US98/25154 



the month, T represents the fixed letter T, hh represents 
the hour of the day, mm represents the minute of the 
hour, and ss represents the second of the minute. This 
time is always assumed to be DTC (Coordinated Universal 
Time) y also known as GMT. The purpose of using Universal 
Tipe is so that stale-dates can be interpreted 
unambiguously! no matter where the Push message components 
may be located. 

T *te format of a DA element is a dock driver 
name such' as ^Browser" or "Skytel", followed by a slash, 
followed by a dock-specif ic address, such as an IP 
address or pager PIN or phone number. This element is 
not present, or has empty content, in a downstream 
document - as sent out by the PAFDC 62. It is inserted by 
the dispatching component of the PAFCC 64 for 
interpretation by the appropriate dock driver. 

The value of the xmlrlang attribute (a standard 
XML attribute) is an RFC-1766 language code; for example, 
the language code for English is en. If the xml:lang 
attribute is omitted, nothing is assumed about the 
language of the text. See 

http://ds.internic.net/rfc/rfcl766.txt for more 
information. 

The value of the CODE attribute is a numeric 
value corresponding to the content of the message. If 
the message must be sent over an unsecured channel, it is 
sent in the form of a telephone number chosen by the 
PAFCC 64 plus the CODE value. Such a message can be sent 
over the simplest of channels — a numeric-only pager. 
This attribute is required. 

The value of the KEY attribute is a digit 
representing which code key (in the pager GUI) this 
response corresponds to. Multiple RT elements within an 
MT element must have different KEY values. This attribute 
is required in a downstream document. in an upstream 
document containing a response which is free-form (not 
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one of the provided responses) , the KEY attribute is not 
present. 

The content of a RE element is always the same 
as the content of the ID element in some other document, 
5 Upstream documents have a RE which links them to the 

downstream element, which links them to the downstream, 
document to which they respond. If a downstream document 
has a RE element, it is meant to supersede the downstream 
document referred to. This is how cancellations and 
10 corrections are sent downstream. 

The content of a CF element is of the form 

Component ,^iame= Value where Component .is PAFDC _62 _or_ PAFCC- 

64 (and possibly . other things) and Name is an element of 
the specified profile. Value is a new value for that 
15 element requested by the customer. This element appears 

only in spontaneous upstream messages. 

The elements within the PAF element must appear 
in the order specified in the table. Only the ID element 
is required, but if any of the others appear, they must 
20 be in the given order, and at most one element of each 

type is allowed. These rules do not apply to RT elements 
when they are nested inside an MT element. 

XML Comments: Comments may be placed anywhere 
in a document except between < and >i They begin with 
25 the string <! — and end with the string — > and may not 

contain the string — (for compatibility with full SGML) . 
Support for comments is an XML requirement, but PAF 
documents typically will not contain them except perhaps 
for debugging purposes. 
30 The following is an example of a downstream 

document . This document has already been processed by 

the PAFCC 64, as it contains a DA element: 

<PAF> 

<ID>asdf jkl</ID> 
35 <CD>19980201T080500</CD> 
<TO>Customer 2 4 </TO> 
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<DA>Skytel/142857</DA> 
<PR>.9</PR> 

<SD>199802Q1T090500</SD> 

<MT xml:lang=en CODE=125>You have too much money in your 
5 401-K account/ 

How much should we move? ' 
<RT KEY=1>100%</RT> 
<RT KEY=2>50%</RT> 
<RT KEY=3>0%</RT> 
10 </MT> 
</PAF> 

The following is an example of an upstream document : 

;^ <PAF> ^ 

<ID>qwertyuiop< / ID> 
.15 <CD>19980201T081000</CD> 

<DA>Skytel/142857</DA> 

<RT KEY=1>100%</RT> 

<AD>1998 0201T090600</SD> 

<RE>asdf jkl</RE> 
20 <ER></ER></PAF> 

The following is another version of "asdfjkl" 

for a Portuguese-speaking customer: 

<PAF> 

25 <ID>asdf jkm</ID> 

<CD>19980201T080500</CD> 

<T0>Customer99</TO> 

<DA>Skytel/242993</DA> 

<PR>.9</PR> 
30 <SD>19980201T090500</SD> 

<MT xml:lang=pt> Você tem demasiado dinheiro em seu 

cliente 401-K. 

Quanto devemos nós mover? 
<RT KEY=1>100%</RT> 
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<RT KEY=2>50%</RT> 
<RT KEY=3>0%</RT> 
</MTX/PAF>. 

The following describes an XML example using, 
5 Internet Protocol (IP) . Not all docks speak IP. This 

discussion refers only to those that do. There are two 
reasonable IP-based strategies for communicating between 
a dock driver and its corresponding docks: TCP/IP streams 
and UDP/IP datagrams.. Here, we will speak of "senders" 
10 and "receivers". For a downstream message, the sender is 

the dock driver and the receiver is the dock itself; for 

. an .upstream message , the sender- is the" dock "arid" the " 

receiver is the dock driver. All issues are symmetrical. 

When the sender wishes to transmit a PAF 
document to the receiver, it may employ TCP or UDP. TCP 
provides reliable transmission, flow control, and a 
positive indication of transmission (the success of the 
"close- socket" system call). Therefore, no high-level 
acknowledgment of success is required. The receiver 
simply reads the entire document and closes the 
connection . 

UDP does not provide any of the above mentioned 
features of TCP, but it has much lower overhead: a normal 
PAF document can be transmitted in a single packet. A 
specific acknowledgement is required, and is defined 
here. The receiver should return a datagram containing a 
minimal PAF document as follows: 

<PAF><ID>xy z < / ID><RE>abc< / rex /PAF> 

, . The "xyz" represents a newly generated unique 
document ID, and the "abc" represents the document ID of 
the document being acknowledged. This minimal document 
is absorbed by the dock, the dock driver or the PAFCC 64, 
and is in no case passed to thePAFDC 62. 

If the receiver detects an error (a malformed 
PAF document, for example), then an error document is 
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generated and sent back to the sender. This document 
would typically look like this: 

<PAF><ID>xyz</ID><RE>abc</RE><ER>error message</ERx/PAP> 

Error messages in ER elements are text strings. 
5 Error messages include, but are not limited to, "Dock 

Full" and "Message Authentication Failed". 

The following section defines the dock for 
plain old telephones service POTS. Messages forwarded to 
this dock make use of commercially available or to-be- 
10 built text-tb-speech systems. 

The customer's phone number is on registry with 
t. K *e PAFCC 64. This can be a cellular or landline phone 
number. Multiple phone numbers may be available to be 
used in turn. 

15 When a message is to be sent, the customer's 

phone is called automatically by the dock driver. The 
tcxt-to-speech system then reads the message to the 
customer along with possible replies, in the general 
fora: "To choose <action 1>, press or say One. To 

20 c.ioose <action 2>, press or say Two." and so on. 

Systems that can recognize the ten spoken digits, plus 
tones generated by keypresses, are readily available. 

In addition, the customer may call a toll-free 
nusber at any time to play back messages heard but not 
25 yet replied to. The * and # keys permit, scrolling 

through the list of messages in priority order, where * 
• ©.ins "Skip to next" and # means "Skip to previous". 
cr.--# a message has been replied to and the customer has 
j up, it is purged from the toll-free number. 

3 0 For international calls, the toll-free number 

c.i. to supplemented with a regular toll number, since 
tcll-rree numbers can typically hot be called from 
c-tside North America. In addition, the world's 
telephone companies are starting to define international 

93 



BNSDOCIO. <WO 9930295A 1 ■ 



WO 99/30295 



PCT7US98/2S154 



toll-free service (country code 800), and obtaining such 
a number might be appropriate. All phone numbers 
whatever would provide exactly the same service. 
However, additional phone numbers might be provided that 
5 rendered servicies in languages other than English. The 

dock driver for the POTS dock would appear much like a 
pager dock. 

The following describes an Internet Dock 
example from both the server and client sides. The 
10 server side will be discussed first, with respect to the 

Figure 24. The Server 1300 is responsible for the 

--transmitting- messages to- the client,- monitoring -the- 

status of transmitted messages, and receiving messages 
from the client. This application, hereafter referred to 
15 as Server, is a series of components designed to scale as 

its use warrants it. ' 

The Server 13 00 supports the following 

services: Format and transmit messages to the client. 

Receive messages from the client. Encrypt all 

20 transmissions. Monitor all transmissions and forward the 

.. . * - ... 

• status to the Response Router. Prioritize outgoing 

messages. Support the transmission to a wide range of 
devices. 

Once the Server 13 00 receives a request to 
25 transmit a message, it then determines the destination 

device transmission characteristics based on the Code 
Field, formats the message, encrypts and transmits it. 
After transmission, the Server 13 00 waits, for a reception 
confirmation message from the Dock • 1302 . Once a 
30 confirmation message is received, the Server waits for 

response message. 

. The Server receives and processes messages from 
the client (i.e. through Dock 1302). These messages 
range from status messages to customer initiated 
35 messages. Once a response is received, the response 
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(i.e., message) is first virus scanned and decrypted. 
After it is decrypted, its is authenticated, formatted, 
and send to the Response Router 128. The Response Router 
1304 is response for forwarding the message to 
appropriate object. 

All receptions and transmissions between the 
Server 1300 and Dock 1302 can be encrypted using the 
encryption handler 1306. 

Once a message is sent downstream, the Server 
1300 will monitor for an updated status from the Dock 
1303. If a response is not received in a specified time, 
the Server 1300 either retransmits the message or sends a 
status message to the Response Router 1304. 
Retransmission is based on the customer's profile and 
15 device. The following are some of the responses the 

Server 1300 will forward to the Response Router 1304: 

When a message (s) was received, along with a 
time stamp; If customer has viewed a message; The time 
and date of the customer's computer; Messages that are 
approaching the stale time threshold and have not been 
responded to by the customer; Messages who's stale time 
expired without a response by the customer; Communication 
error messages; and Customer initiated messages 

Since the number of outgoing messages may 
exceed the capacity of the transmitting equipment, the 
Server 1300 is able to prioritize outgoing message based 
on criticality level and stale time. The server 1300 can 
also serve as a repository for messages that, because of 
device memory constraints, have been deleted from the 
30 device. In this event, the customer can view messages 

upon requesting that they be delivered from the Server 
1300 to their device. Should the Server 1300 not be able 
to transmit a message before its stale date is reached, 
it will inform the Response Router 1304 of this 
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condition. The Server 1300 then removes the message from 
its message queue and marks it accordingly. 

The Sever must support a wide range of Docks 
13 02. The Docks 1302 can range from Personal Computers 
5 to PalmPilot devices. 

The Server 1300 is an integral component of the 
system. Its function is to concurrently send and receive 
messages. The Server 1300 consists of several objects, 
which support these functions. These objects are: 
10 DownstreamHandler 1308; EncryptionHandler 1306; 

TransmitReceiveHandler 1310; MessageHandler 1312; 
Authenticatior^andler 1314; Decr^ 
UpstreamHandler 1313 

The DownstreamHandler 1308 is responsible for 
15 receiving messages from the Transmit Distributor 1302. 

It is also responsible for resolving any communication 
errors that may occur during inter-process 
connunications. Upon receiving and validating the 
message, this object sends the message to the 
20 MessageHandler 1312. 

Downstream tasks include processing messages 
for transmission and . reprioritizing messages. 

For message transmissions, this object 
determines the destination device characteristics (e.g., 
25 lp Address, hours of operation) from the customer's 

profile and message format. Once the device 
characteristics are determined, the message is formatted 
accordingly and sent to the EncryptionHandler 1306. 

Reprioritization requires the MessageHandler 
30 to determine when a message should be transmitted. 

Tr determine the message's priority, two elements are 
c .*^ ; jered: Message's criticalty level and expiration 
*\ * date. , For, example, a message was originally marked 
as tnc tenth message for transmission. The 
35 MessageHandler 1312 determines, it should -be the second 

arsj then reprioritizes it. 
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This EncryptionHandler 1306 is responsible for 
encrypting the XML response document for transmission to 
the Dock 1302, 

The TrarismitReceiveHandler object 1310 is 
5 responsible for physically transmitting and receiving 

messages to/from the Dock 1302. The individual Dock 1302 
drivers^ communicated with this object to transfer the 
message. As' new Dock 1302 devices are introduced, their 
dock drivers only have to interface with the object. 
10 This object is also responsible for resolving any 

communication errors that may occur during communications 
With the Dock 13 02. 

The MessageHandler 1312 is responsible for 
processing downstream and upstream messages. 
15 The AuthenticationHandler object 1316 is 

responsible for authenticatinig the incoming messages. If 
a message fails authentication, the MessageHandler 1312 
is informed and an alert is sent to the Response Router 
1304. The MessageHandler 1312 then waits for 
20 instructions from the Transmit Distributor ±320. 

The DecryptionHandler object 1316 is 
responsible for decrypting the upstream message. 

The UpstreamHandler object 1318 is responsible 
communicating with the Response Router 1304. It is also 
!5 responsible for resolving any communications errors 

between the two objects. 

Upstream tasks include monitoring the status of 
messages and sending the messages to the Response Router 
1304. 

0 Monitoring of messages requires the 

MessageHandler 1312 to either determine if a response has 
been received for "push" message or analyzing responses. 
If a response has not been received during a specified 
time, the MessageHandler 1312 will either have the 

5 message retransmitted or remove the message from the 

message queue. In any event the Response Router 13 04 is 
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informed of the action. If a response has been received, 
the MessageHandler 1312 determines if a message should 
be retransmitted, wait for additional status updates, or 
remove the message from the message queue. For example, 
communication errors would require that a message be 
retransmitted. status updates, such as "message has been 
received", simply requires the MessageHandler 1312 to 
keep waiting for a customer -response, customer responses 
are formatted (e.g., date and time received are added), 
forwarded to the UpstreamHandler 1318, and then deleted 
from the message queue. . 

_ ^ Figure 25_ illustrates^ scenario-where an XML 

message, is sent to the Dock 1302 and processed by the 

customer. The customer's response is sent back to Server 
15 1300 yia Dock 1302 

Figure 26 illustrates an example where multiple 
XML messages are received asynchronously. The customer 
does not view the original message and, consequently, an 
updated transaction is sent and original message is 
20 removed, from the message queue. 

The following describes the functionality of 
the internet Dock side of the system (traditionally 
called the client). An Internet Dock is responsible for 
receiving messages from the Server 1300, processing the 
customer's responses, and transmitting the response back 
to Server 1300. This section only addresses the 
application on the customer's system, and not on the 
. transmission side. This application, hereafter referred 
to as pock, is a smart Dock, capable of offering a wide 
30 range of services to the customer. The Dock resides 

on a customer's intelligent device. The Dock supports 
the following services: Receive and display messages; 
Allow the customer to respond to "push" messages, process 
, them, and transmit responses to the Server 1300; Encrypt 
35 all transmissions 
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Automatically alert the customer to incoming messages; 
Prioritize multiple incoming messages; Allow the customer 
to view , of f-line previously received messages that were 
not responded to; Allow the customer to view processed 
responses (i.e., messages and their responses) and 
confirmation information; Automatically delete historical 
processed messages at a predefined date; Allow the 
customer to delete historical processed messages. 
Provide the Server 13 00 with the status of the 
transmitted message; Allow the Server to automatically 
delete and reprioritizes messages that were not viewed by 
the customer; Support an alternative applet security 
implementation (i.e., applet mating); and Allow the 
customer to initiate communications with operator of the 
Server 13 00 to change their customer profile. 

When an encrypted message is received from the 
Server, a message notification is exercised, and the 
customer is prompted -to enter their Personal 
Identification Number (i. e. , PIN) . This PIN is then 
validated, and if correct, displays the" message and its 
response. Otherwise, will keep retrying and display a 
message to contact Customer Service for assistance. 

The customer has the option of selecting a 
response from, a list of responses that were sent from the 
Server 13 00. Once the selection is made, the customer 
then issues a command for it to be transmitted back to 
the Server 1300. The response is then stored locally and 
encrypted for transmission. Once it's encrypted, the 
Dock sends it to the Server 13 00 and receives a 
confirmation of receipt. The confirmation is then 
displayed to the customer for acknowledgment. If an 
error is encountered during transmission, the customer is 
informed of an error and the appropriate action- The 
customer also has the option of responding to a message 
35 off-line. 
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All receptions and transmissions between the 
Dock and the Server 13 00 are encrypted. The Server 1300 
will determine the appropriate encryption method. 

Once a message is received, the Dock will 
5 notify the customer of an incoming message by a method 

specific to the customer's device. If multiple messages 
are received, the notification message will include the 
total number of incoming messages. The customer must 
then acknowledge the alert. Once acknowledged, message 
10 processing is as described above. 

If multiple messages are received concurrently, 
the Dock prioritizes these messages based on their 
priority level. After a message has been processed, the 
next message is displayed for the customer to respond. 
15 All subsequent messages are processed in this fashion. 

If the customer chooses to view messages off-line, then 
the unprocessed messages are displayed first in priority 
order , followed by processed messages. 

The Dock allows the customer to view 
20 unprocessed messages off-line. The customer chooses the 

unprocessed message option to enter this mode. Once 
selected, the messages are displayed in. priority order. 
The Dock will also display a notification dialog box, 
reminding the customer they have unprocessed messages in 
25 the queue. Should the customer reconnect (i.e., on-line) 

when viewing previously received message, . the unprocessed 
messages are displayed first, unless the new messages 
have a priority that supersedes all messages. 

. The Dock maintains a historical database of 
30 processed messages along with their responses and 

confirmation. Each message is date and time stamped. 
Should multiple messages be received for the same 
transaction, these messages will be group by date order. 
The customer has the option of viewing a list of all the 
35 messages, with a brief description, selecting a 
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transaction, and then viewing the details of each 
message 

The Dock automatically deletes historical 
information, when the disk spaces (e.g., hard disk, 
5 PCMCIA EEPROM) or data limits are reached. The type of 

device will determine the limit for the disk space. Date 
limits are based on the oldest stored messages. These 
deletions are necessary to clean up the customer's 
device. * Typically, only the oldest messages will be 

10 deleted. The only exceptions to this deletion function, 

are messages that were marked as protected by the 
customer. These messages must be marked unprotected 
before thiey can be removed. 

The Dock allows the customer to delete 

15 processed messages. Prior to the deletion, the customer 

is asked to confirm the deletion. 

The Dock provides the Server 13 00 with status 
of the transmitted message. Some of the status messages 
are: When a message (s) was received, along with a time 

20 stamp; If customer has viewed a message; If the customer 

has composed a response to a message, but has not 
transmitted it; The time and date of the customer's 
computer; Messages that are approaching the stale time 
threshold and have not been responded to by the customer; 

25 Messages whose stale time expired without a response by 

the customer ; 

Inform the Server of a change in a message state; and 
Communication error messages. 

The Dock will allow the Server 13 00 to delete 

30 and reprioritizes any messages that were received by the 

Dock, but not viewed by the customer. For example, a 
message is received stating "your account is overdrawn by 
$2 million dollars", along with appropriate responses, 
but the customer has chosen not to read it. 

3 5 Subsequently, another message for the same account is 

received with a different amount. The Dock will delete 



the original message and forward, the new message* The 
Dock will inform the customer of this change. 
Additionally, if a message is received with a different 
priority, the Dock will automatically reprioritize any 
messages not viewed by the customer. 

As previously stated, most of the examples 
provided in this description use XML documents to send 
and receive information. An alternative method, is to 
supply the AppletViewer with an incomplete applet (i.e., 
a program). This applet becomes functional once is 
"joined" with another applet sent by the Server 1300. 
This process is described as applet-mating. In other 
words, the Server 1300 sends an applet to the customer's 
system, the AppletViewer validates the received applet, 
and links it with the applet residing on the device. 
Once linked, the information is, displayed to the 
customer. Should the applet fail its validation, the 
customer is asked to contact Customer Server Service. 

This type of communication provides an 
additional layer of security and functionality over the 
purely XML examples used in the rest of this description 
For example, the , applet-XML combination provides for a 
standard method of displaying the push messages, which 
typically only differ in message content. In comparison 
applet-mating provides for enhanced display and 
processing capabilities. These enhancements are due to 
the fact that instead of using a dpcument to provide 
information, a program is used. This program provides, 
in addition to document information, the GUI (i.e., 
graphical user interfaces) and controls. The applet 
residing in Dock allows the linked application to 
communicate with the other Dock objects. 

The Dock will allow the customer to change 
their customer profile information and transmitted to 
Chase for processing. The customer for example will be 
able to change their calling priority. Once the Dock 
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has been installed on the customer's device, it remains 
active at all times listening for an incoming push from 
the Server .13 00* The Dock as illustrated in Fig* 27 
consists of two major components: Listener 1402 and 
5 Applet Viewer 1404. Each major and minor component shown 

in Figure 27 is detail below. Figures 28 and 29 depict 
in time sequence the processing occurring in a Dock. 
Figure 28 illustrates a scenario where a Dock is 
processing one Push message. Figure 29 shows the 
10 processing conducted in a Dock for multiple Push messages 

with different priorities. 

The Listener 1402 is responsible for receiving 
push messages from the Server. Once installed, the 
Listener 14 02 remains active at all times waiting for 
15 messages. The device is capable of operating in either 

True-push or Smart-pull mode. It communicates with the 
computer's physical communication component 14 06 (e.g., 
modem, wireless modem, LAN connection, etc.) 

In the True-push mode the Listener 1402 
20 operates in receiver mode, waiting to be interrupted by a 

message that was sent by the Server. True-push mode 
allows for information to be sent directly to the 
customer by the Server. In the Smart-pull mode Listener 
14 02 polls the Server at predetermined times for any push 
25 information. Once information is available, it is 

automatically downloaded to the customer's device. 

Regardless of which mode is used, once the 
Listener 1402 receives a "push" message, it automatically 
loads the Applet Viewer 1404. If the Applet Viewer 1404 
30 is loaded, then the Listener 1402 sends the information 

to the Applet Viewers Transmitter/Receiver component 
1408. 

"Information" as used above may be a Java 
applet, XML document, or any other type of component, 
35 which is capable of delivering a message. For the 
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purposes of this technical note, an XML document is used 
as the medium for the message. 

The Applet Viewer 1404 is directly responsible 
for displaying the "push" message and capturing the 
customer's response. It is also responsible for 
displaying both stored unprocessed and processed 
messages. This method of processing allows the customer 
to view messages off-line. The Applet Viewer 1404 
consists of nine objects: Transmi tter /Receiver ; 
Decryption; Formatter; DisplayApplet; ResponseExtractor; 
Encryption; MessageHandler; GUI Viewer Vcontroller; 

The transmitter/receiver object 1408 is the " " 

communications layer responsible for sending and 
receiving information from the physical communication 
15 component. This component also receives the message from 

the Listener 1402 when the AppletViewer 1404 is loaded 
into memory. The MessageHandler 1420 communicates 
directly with this component. 

The MessageHandler object 1420 is responsible 
20 for directing the flow of the message. If the message is 

downstream, it directs the message to the Decryption 
object. If the message is upstream, it sends the message 
to Transmitter/Receiver 1408. This object is also 
responsible confirmation processing, cleanup, 
25 prioritizing, and error processing. 

When a response is sent to the Server, the 
message is temporary stored in the Push Message queue. 
The MessageHandler 1420 then waits to receive a 
confirmation from the Server. if a confirmation message 
is received, the push message is deleted (i.e., cleaned 
up) from the queue and the confirmation message is sent 
to the GUIViewer 1422. If the confirmation is not 
received, the MessageHandler 142 0 retries! If after 
retrying for a specified number of times, an error 
message is displayed informing the customer to call 
Customer Service for assistance. The next time the 
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AppletViewer 1404 is loaded into memory, it sends the 
response with the appropriate error code. 

This object 1420 is also responsible for 
prioritizing unprocessed (i.e., not viewed) messages. If 
5 multiple messages are received concurrently, this 

component will send the message to the Decryption 1410 
object priority order. The message's priority is 
embedded in the message. If the received messages all 
have the same priority, then each message is sent 
10 sequentially. Note, for each session (i.e., message is 

displayed and the response is captured) , the customer 
will be prompted to enter their PIN number prior to start 
of the session. 

Should the customer choose not to process any 
15 messages, the unprocessed messages are stored in the Push 

Message queue 1426. 

Finally this component 1420 is responsible for 
sending and/or detecting any communication and processing 
errors that may have occurred during the session. 
20 The System must ensure that a high level of 

security exists whenever the device can support it. The 
Dock 1400 will support the recommend security standard. 
For example, if an XML message is sent to the Dock 1400, 
the original message will be encrypted at the originating 
25 site prior to transmission. Thus any message must be 

first be decrypted by Decryption 1410 object prior to its 
use. When a message is first received, this object will 
retrieve the encryption key from the System Information 
1428 and then apply it to the message header, 
30 :ch contains the PIN. This information is then sent to 

t»;e DisplayApplet . 1414 object. Once the customer's PIN 
ti\% been validated, the DisplayApplet 1414 informs this 
cfc;ect and the message contents are then decrypted. The 
decrypted message is then sent to the Formatter 1412. 
35 Tnc process is repeated for each message. This object 
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1410 also decrypts previously unprocessed and processed 
messages in the Push Message queue 1426. 

The Formatter 1412 is responsible for matching 
(i.e., mating) the message (i.e., transmitted file) to 
5 the native applet (i.e., program residing on the 

customer's computer), thus creating the display applet 
that will be viewed. Once the applet is created, it is 
sent to the Display Applet 1414 component. Note: The 
term applet may either be a program or scripting language 
10 arid not tied to any development language or platform. 

For example, two possible program structures for the 
display applet may be messages written in XML (i.e., 
scripting language) and Java ( i . e. , programming 
language) . 

15 For an XML messages, the native applet uses the 

XML document for data used to populate the text fields. 

For Java messages (i.e., or similar file 
structures), the Formatter 1412 uses the two applets 
(i.e., message and native applet) to create (i.e., link) 

20 a functional applet from the two applets. Prior to the 

creation of the functional applet, the message and native 
applets are non-functional (i.e., cannot be executed)). 

The DisplayApplet object 1414 is responsible 
for displaying the push message, processing the 

25 customer's keystrokes, and capturing the customer's 

response and a customer-specified stale date, the date 
upon which Server must process the response or else 
consider the response void. This component is also 
responsible for validating the customer's PIN. 

30 The Response Extractor object 1416 is 

responsible for formatting the customer's response into 
the proper format. It receives the customer's responses 
from the Response Extractor 1416. One possible format 
for the response is an XML' document, though other 

35 languages or formats may be used. 
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The Encryption object 1418 is responsible for 
encrypting the XML. response document for transmission to 
the Server- It is uses the encryption key stored in the 
System Information Database 1428. 

The GUIViewer object 1422 is responsible for 
three principal functions. First it displays unprocessed 
and processed messages. Processed message are first 
retrieved from this object and then sent to the 
DisplayApplet 1414 object for processing. The historical 
processed messages are displayed in a list and then the 
customer has the option of viewing the details (e.g. , 
original message, response, confirmation, and date/time 
stamp) . This object also displays the confirmation and 
error messages, as well as providing navigational options 
(e.g., menus, lists, etc.). 

Second, the GUIViewer 1422 localizes the object 
will localize the display and controls (e.g., menus and 
text fields) . This object will determine the locale by 
the version of the customer's computer operating system. 
The option also exists to localize the GUI, based on the 
customer's profile, independent of the operating system. 
The XML message format includes provisions for localizing 
the message. Locale information can be stored in 
resource files or in the System Information Database 
1428. 

Thirdly, the GUIViewer 1422 acts as the primary 
interface for customer initiated messages. The customer 
can request changes to their profile from a menu option. 
Upon selecting this option, the customer is presented 
with several profile change options. After entering 
their changes, the customer then elects to send their 
changes to the Server. Upon this selection, the changes 
are formatted and encrypted. The AppletViewer 1404 then 
establishes a communications connection with Chase and 
transmits the changes . 
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The Vcontroller object 1424 is responsible for 
the retrieval of unprocessed and historical processed 
messages from the Push Message queue 1426 and controlling 
their decryption and formatting. Messages are retrieved 
5 in priority and stale date order, where stale date has 

the greater precedence. This object will also 
periodically (at a specified time) check the Push Message 
queue 1426 for any messages that have a stale date 
reaching their expiration threshold. If the threshold is 
10 being reached, this object will send an ; alert reminder 

. message to the GUIViewer object 1422. 

_ _ ?*§P**"*s. J3 0-3 2 ^contain _thr T ee„seq^ _ 

illustrating further Dock processing. Figure 30 depicts 
an. applet being sent to the .dock .instead of an XML 
15 document. The applet is then, mated with the Dock's 

inactive applet. Figure 31,. illustrates the 
reprioritization and cleanup of unprocessed messages. 
While a message is being processed by the customer and 
another message is in the queue, a new message arrives 
20 which supersedes the queue's message. Figure 32 depicts 

a scenario where a customer initiates a change to their 
customer profile and transmits the changes to the Server. 

The following section describes 
Pager/Processing, components which are responsible for 
25 transmitting a message (s) from the system to a customer 

and retrieving the customer response (s) from a paging 
. company's network., 

; This section addresses the transmission and 
r«? ^options of two and one-way pager messages. Paging 
30 tirv;ces are ; defined as devices that support either two- 

biy ^transmission (i.e., message transmission and- response 
reception) or. one-way transmission (i.e. from the system 
to the Customer) and adhere to the standard paging 
architectural. Additionally,, this section addresses the 
3 5 application from the server side. This application, 



108 



BNSDOCID: <WO 9930295A 1 



r-'.WO 99/30295 PCT/US98/25154 



10 



hereafter referred to as Seirver, is a series of 
components designed to scale as its use warrants it. 

As depicted in Figure 33 Pager Processing 
components 1500 reside at the Server and utilize the 
paging company / s network to communicate with the 
customer's pager. These separate components form the 
Page Processing Architecture. The Architecture will 
support the following services: format and transmit 
messages to the client's one-way 1502 or two -way pagers 
1504; retrieval of customer's responses and status from 
intelligent pagers (e.g. two-way pagers and Skywriter 
2000) ; encrypt all transmissions; monitor all 
transmissions and forward the status to the Response 
Router 1506; prioritize outgoing messages; and Support 
15 the transmission to a wide range of pagers. 

Once the Server 1508 receives a request to 
transmit a message, it then determines the destination 
device transmission characteristics based on the Code 
Field, formats the message, encrypts and transmits it. 
20 After transmission, the Server 1508 waits for a reception 

confirmation message from the Pager 1502, 1504. Once a 
confirmation message is received, the Server 1508, waits 
for response message. 

The Server 1508 receives and processes messages 
25 from the Dock 1502, 1504, (i.el pager) via the NOC (i.e. 

Paging Company's Network Operating Center) . These 
messages range from status messages to customer initiated 
messages. Once a response is received, the response 
(i.e. message) is first virus scanned and decrypted. 
30 After its decrypted, : it is authenticated, formatted, and 

send to the Response Router 1506. The Response Router 
1506 is responsible for forwarding the message to 
appropriate object. 

All receptions and transmissions between the 
35 Server 1508 and Dock 1502, 1504 are be encrypted. The 

Server 1508 determines the appropriate encryption method. 
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Once a message is sent downstream, the Server 
1508 will monitor for an updated status from the Dock 
1502, polling the NOG. If a response is not received in 
a specified time,, the Server 1508, either retransmits the 
5 message for non-intelligent devices or sends" a status 

message to the Response Router 1506. Retransmission is 
based on. the customer's profile and device. The 
following are some of the responses the Server 1508 will 
forward to the Response Router 1506: When a message (s) 
10 was received along with a time stamp; if customer has 

viewed a message; messages that are approaching the state 

_-ti»e_ threshold _and have. not_been responded to -by the 

customer; messages who's stale time expired without a 
response by the customer; communication error messages; 
15 and customer initiated messages. 

Since the number of outgoing messages may 
exceed the capacity of the NOC, the Server 1508 is able 
..to prioritize outgoing messages based on priority level 
and. stale time. Should the Server 1508 not be able to 
transmit a message before its stale date is reached, it 
will inform the Response Router 1506 of this condition. 
The server 1508 then removes the message from its message 
queue and marks it accordingly . ' 

The Server 1508 must support a wide range of 
25 pagers 1502, 1504. .These pagers 1502, 1504 can range . 

from one-way devices to Java enabled devices once they 
. t are , introduced. 

Unlike other intelligent devices, the two-way 
pagers 1504 do not presently allow a bank or other 
organization to develop unique services for the pager. 
For example, the following services are not supported in 
either two-way or one-way pagers. Automatic cleanup 
messages cannot be. deleted automatically at the client 
side and must be deleted by the customer. This 
limitation implies the Server 1508 could conceivably fill 
a customer's pager with messages. While this is not a 
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problem with one-way pagers (i.e. these devices only 
store one copy of a duplicate telephone number), two-way 
pagers will store duplicate messages. Once a pager 
allows the Server 1508 to remotely delete unread 
5 messages, then this feature can be supported. Message 

prioritization: r- since the Server 1508 does not have 
direct access to a customer's pager, messages at the 
client side cannot be prioritized. Encryption - 
presently/ pagers do not support encryption or Java 
10 Virtual Machines (i.e. JVM). As a result, "push 11 

transmission will be generic in scope and will not 
contain any, sensitive information at this time. Once 
encryption, and/ or Java becomes available, then transmit 
messages can be customized and encrypted. 
15 The Server 1508 is responsible for two modes of 

communications; transmission and reception of customer 
messages. Like the Internet Dock Server (see Fig. 24) it 
is designed to function concurrently in the two modes. 
The Server 1508 consists of several objects, which 
20 support these functions. These objects are: 

DownStreamHandler 1510; EncryptionHandler 1512; 
TransmitHandler 1514 ; MessageHandler 1516; 
Au then ticationHandler 1518; DecryptionHandler 1520; and 
UpstreamHandler 1522. 
25 The DownstreamHandler 1510 is responsible for 

receiving messages from the Transmit Distributor 1524. 
It is also responsible for resolving any communication 
errors that may occur during interprocess communication. 
Upon receiving and validating the message, this object 
30 sends the message to the MessageHandler 1516. 

The MessageHandler 1516 is responsible for 
processing downstream and upstream messages. Downstream 
tasks include processing messages for transmission and 
reprioritizing messages. 
35 For message transmission, this object 1516 

determines the destination device characteristics (e.g. 
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PIN number, hours of operation) from the customer's 
profile and message format. Once the device 
characteristics are determined, the message is formatted 
accordingly and sent to , She Encrypt ionHandler 1512. 

Reprioritization. requires the MessageHandler 
1516 to determine when a message should be transmitted. 
To determine, the message's priority, two elements are 
considered: Message's priority level and expiration 
stale date. For example, a message was originally marked 
as the tenth message for transmission. The 
MessageHandler 1516 determines .it should be the second 

. and , then rep . rior _ itize s. it : . Additionally,. . for. messages . . 
for non-intelligent devices . are retransmitted as per 
their customer profile. For: example, a customer profile 
states that if they do not respond to a page in one hour 
and another page should be sent out. The MessageHandler 
1516 tracks the time between transmission and transmits 
it accordingly. 

Upstream tasks: include monitoring the status of 
messages and sending the messages to the Response Route 



1506. 



Monitoring of messages requires the 
MessageHandler 1516 to either determine it a response has 
been received for "push" message. or analyzing response. 
If a response has not been received during a specified 
. time, the MessageHandler 1516 will either have the 
message retransmitted or remove the message from the 
message queue 1528. in any event, the Response Router 
1506 is informed of the action. if a response has been 
received, the MessageHandler 1516 determines if a message 
should be retransmitted, wait for additional status 
updates, or remove the message from the message queue. 
For. example, communication errors would require that a 
message be. retransmitted. Status updates, such as 
"message has been received", requires the MessageHandler 
1516 to keep monitoring for a customer response. Whereas 
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customer responses are formatted (e.g. date and time 
received are added) forwarded to the UpstreamHandler 1522 
and then delete from the message queue 1528. Note the 
MessageHandler 1516 must poll the paging company's 
5 database to obtain the status and/or message. 

The Transmit/ ReceiveHandler object 1514 is 
responsible for physically transmitting and receiving 
messages to/ from the Dock via the Paging Company 153. 
Typically, communications between the Server 1500 and the 
10 paging company 153 0 is done via a leased line. The 

individual Dock drivers communicate with this object to 
transfer the message. Thesis dock drivers are the paging 
company's 1530 communication protocols. 

As new Dock devices 1502, 1504 are introduced, 
15 their drivers only have to interface with this object 

1514. This object 1514 is also responsible for resolving 
any communication errors that may occur during 
communications with the Dock 1502, 1504. 

The EncryptionHandler object 1512 is 
20 responsible for encrypting the message for transmission 

to the Dock 1502, 1504. The approved security standard 
will be used for encryption. If the paging company 1530 
only provides encryption, then this object is not needed. 
The DecryptionHandler object 1520 is 
25 responsible for decryption of the upstream message. If 

the paging company 153 0 only provides decryption, then 
this object is not needed. 

The AuthenticationHandler object 1518 is 
responsible for authenticating the incoming messages. If 
30 a message fails authentication, the MessageHandler 1516 

is informed and an alert is sent to the Response Router 
1506. The Messagehandler 1516 then waits for 
instructions from the Transmit Distributor 1524. 

The Upstream Handler object 1522 responsible 
35 communicating with the Response Router 1506. It is also 
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responsible for resolving any communications errors 
between the two objects. 

Paging Company Receiver 1530 is not the 
Server's domain, it is responsible for communicating 
directly with pagers 1502, 1504 and the" 

TransmitReceiveHandler 1514 . All communication messages 
are stored in the Pager Message Queue 1532 for retrieval 
by MessageHandler. 

Figure 34 illustrates the process flow of a 
message from the Server 1508 to a paging device 1502, 
1504 and the response thereto. 

T« e - Push Banking-system teaches a new method" of 

communications called "metanetworking. " Previous 
communications systems concerned themselves with sending 
a message from one terminal "across a network to a 
receiving terminal. Sometimes networks were linked, e.g. 
an internal Lotus Notes E-mail system is linked to the 
Internet e-mail or a computer network notifies a 
technician via pager that a component has gone down. 

Metanetworked communications rises above 
standard network software and hardware systems and acts 
as an "orchestrator" for general communications needs. 
The primitive subjects of a metanetwork are 1) the Sender 
and Receiver/Responder as communicating persons and or 
entities and 2) the Message (i.e. the "application layer" 
content of a message or its meaning) . 

Metanetworking requires features ordinary 
network don't have l) The Sender's reasons for sending a 
message, the Receiver/Responder' s rules for accepting 
messages and the actual content of the message must be 
stored in profiles, queues and caches and constantly be 
re-evaluated across the dimension of Time and vis-a-vis 
the capabilities of the standard communications networks 
(e.g. via artificial intelligence control tools). 2) All 
existing networks must be accessible to the metanetwork 
in order to optimize message delivery. 3) once a message 
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is responded to or goes "stale" copies of it in other 
networks or on other devices must be cleaned out of the 
system. 4) .Messages must be reprioritizable "on the fly" 
in order to respond to changing situations of the Sender 
5 and /or Receiver. 

The Push Banking system is an instantiation of 
a metanetwork. The Communications, Decision making and 
Caching Component (CDMC) 1100 (Figures 22 and 23) is the 
basic functional unit of a metanetwork communications 
10 system. 

Although the present invention has been 
described in relation to particular embodiments thereof, 
many other variations and modifications and other uses 
will become apparent to those skilled in the art. It is 
15 preferred, therefore, that the present invention be 

limited not by the specific disclosure herein, but only 
the gist and scope of the disclosure. 
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WHAT IS CLAIMED : 

.1. • A method comprising: 
identifying information related to a 
subscriber ; 

5 identifying at least two different channels of 

communication with which to communicate with the 
subscriber; 

creating a message, containing the information, 
the message further containing response information 
10 enabling the subscriber to generate and transmit a 

response to the message oyer at least. one of the two 

.channels of communication; and 

transmitting the message to the subscriber 
contemporaneously on the at least two different channels 
15 of communication. 

2. A method as recited in claim l, further 
comprising receiving a response to the message from 
the subscriber. 

3. A method as recited in claim 2, wherein the 
information is related to at least one account of the 
subscriber, the method further comprising altering the at 
least one account of the subscriber in response to the 
response from the- subscriber. 

4. A method as recited in claim 2, further 
comprising authenticating the transmitted message and the 
received response. 

: 5. A method as recited in claim 1, wherein the 
act of identifying the information further includes 
monitoring at least one data source for information which 
affects the subscriber. 
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6. A method as recited in claim 5, wherein the 
subscriber has accounts at a financial institution and 
wherein the monitoring step includes monitoring the 
accounts. 

i ,: 7. A method as recited in claim 5, wherein the 
method is ; performed on a system and wherein the 
monitoring step includes monitoring databases within the 
system and monitoring external data sources. 

8.. A method as recited in claim 1, wherein 
there are, a plurality of subscribers, the method further 
comprising performing each of the method steps for each 
of the subscribers. 

9. A method as recited in claim 1, further 
comprising: 

creating a plurality of messages; 

establishing a priority of the plurality of 
messages; and 

wherein the step of transmitting includes 
transmitting messages in accordance with the established 
priority. . ■ 

10. A method as recited in claim 1, further 
coaprising retransmitting a message if a response has not 
been received from the subscriber in a predetermined 
period of time. 

11. A method as recited in claim 1, further 
comprising receiving an acknowledgement that the message 
was successfully transmitted over at least one of the at 
lei st two channels of communication. 
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12. A method as recited in claim 1, further 
comprising encrypting the message prior to its 
transmiss ion . 

13 * A method as recited in claim 1 , further 
comprising formatting the message for each of the at 
least two channels of communication prior to 
transmission. 



14, A method as recited, in claim 1, wherein 
the information is time critical. 

_ _ _ „ 15 ____ „..^_ method as recited in" claim 1", " further 

comprising: 

identifying at least one alternative channel of 
communication with which to communicate with the 
subscriber; and 

transmitting the message over the at least one 
alternative channel of communication if a response has 
not been received from the subscriber in a predetermined 
period of time. 

16. A method as recited in claim 1, further 
comprising assigning a time at which the message will 
become stale. 

17. A method as recited in claim 16, further 
comprising periodically retransmitting the message until 
the message becomes stale or until a response , is received 
from the subscriber. 

18. A method comprising: 
identifying information related to a 

subscriber's account; 

creating a message containing the information; 
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embedding the message in an applet, the applet 
providing functionality for the subscriber to display the 
message, to. respond to the message, and to alter the 
subscriber ' s account ; and 

transmitting the applet to the subscriber. 

19. A method comprising: 
identifying information related to a 

subscriber; 

identifying at least one channel of 
communication with which to communicate with the 
subscriber; 

creating a message containing the information; 
transmitting the message to the subscriber on 
the at least one channel of communication; 

receiving a response from the subscriber; and 
correlating the response to the message. 

20. A method a recited in claim 19, the method 
further comprising: 

creating transmission information indicating 
that the message was transmitted; and 

wherein the step of correlating includes 
modifying the transmission information indicating the 
response has been received. 

21. A method a recited in claim 19, wherein 
the information is related to at least one account of the 
subscriber, the method further comprising: 

altering the at least one account of the 
subscriber in response to the response from the 
subscriber . 

22. A method of communicating with subscribers 
to a system, the method comprising: 
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establishing subscriber profiles for a 
plurality of subscribers/ the subscriber profiles 
containing information related to subscriber 
identification, preferred channels of communication and 
alternative channels of communication; 

. ■ - . periodically scanning at least one of databases 
internal to the system and data sources external to the 
system for first information which affects any of the 
plurality of subscribers; 

actively monitoring at least one of the 
databases internal to the system and data sources 
external ; to the system for updates and identifying second 

information, which, affects any _of -the plurality _of _ 

subscribers; 

• : . determining if any of the first and second 
information should be communicated to any of the 
plurality of subscribers, any such information so 
determined being denoted as determined information; 

creating at least one message containing the 
determined information; 

identifying at least one of the plurality of 
subscribers to which the determined information should be 
cornmunicated; 

retrieving from the ' subscriber profile, the 
information related to the preferred channels of 
coaaunication for the at least one of the plurality of 
subscribers; 

formatting the at least one message for the 
preferred channels of communication for the at least one 
cr the plurality of subscribers; 

encrypting the at least one message; 

assigning a time at which the at least one 
r,sage will become stale; 

transmitting the at least one message over the 
prererred channels of communication for the at least one 
ef the plurality of subscribers; 
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monitoring for receipt of an acknowledgement of 
successful transmission of the at least one message over 
at least one of the preferred channels of communication 
for the at least one of the plurality of subscribers; 

, fc if an acknowledgement is not received in a 
first predetermined; time, retrieving from the subscriber 
profile, the information related to the alternative 
channels of communication for the at least one of the 
plurality of subscribers, and transmitting the at 

-least one message over the alternative channels of 
communication for the at least one of the. plurality of 
subscribers; 

monitoring for receipt of a response from the 
at least one of the plurality of subscribers; 

if the response from the at least one of the 
plurality of subscribers has not been received in a 
second predetermined period of time, retransmitting the 
at least one message over at least the preferred channels 
of communication for the at least one of the plurality of 
subscribers ; 

terminating the retransmission step if the at 
least one message has become stale; 

receiving the response from the at least one of 
the plurality of subscribers; and 

authenticating the response from the at least 
one of the plurality of subscribers, 

23. A method . comprising: 

identifying information related to at least one 
account of a subscriber; 

identifying at least one channel of 
communication with which to communicate with the 
subscriber; 

creating a message containing the information, 
the message further containing response information 

V 
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enabling the subscriber to generate and transmit a 
response.; 

transmitting the message to the subscriber on 
the at least one channels of communication; 

receiving a response to the message from the 
subscriber; and 

altering the at least one account of the 
subscriber in response to the response from the 
subscriber. ...... 

24. A system for communicating with a 
..:5« bs ?^ber to the system,, .the , system -comprising: 

an information identification module 
identifying update information related to the subscriber ; 

a subscriber database containing channel 
information which identifies at least two different 
channels of communication with which to communicate with 
the subscriber; 

.a message generation module coupled to the 
information identification module and generating a 
message containing the update information, the message 
further containing response information enabling the 
subscriber to generate and transmit a response to the 
message over at least one of the two channels of 
communication; and 

a communication layer coupled to the message 
generation module, the communication layer including 
interfaces to the at least two channels of communication, 
the communication layer transmitting the message to the 
subscriber contemporaneously on the at least two 
different channels of communication. 

25. A system , as recited in claim 24 wherein 
communication layer receives a response to the message 
from the subscriber, the system further comprising a 
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response module coupled to the communication layer and 
processing the response from the subscriber. 

26. A system as recited in claim 25 wherein 
the update information is related to an account of the 
subscriber, the system further comprising an alteration 
module coupled to the response module, the alteration 
module altering the account of the subscriber in response 
to the processing of the response by the response module. 

27. A system as recited in claim 25, further 
comprising an authentication module coupled to the 
message generation module and coupled to the response 
module, the authentication module authenticating the 
message generated by the message generation module and 
authenticating the response processed by the response 
module. 

28. A system as recited in claim 24, further 
comprising at least one data source, wherein the 
information identification module is coupled to the at 
least one data source and monitors the least one data 
source for the update information. 

29. A system as recited in claim 28, wherein 
the at least one data source is an account information 
data source at a financial institution. 

30. A system as recited in claim 28, further 
comprising an external database interface, wherein the 
information identification module is coupled to the 
external database interface and monitors the external 
database for the update information. 

31. A system as recited in claim 24, wherein 
there are a plurality of subscribers to the system. 
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32. A system as recited in claim 24, wherein 
the message generation module generates a plurality of 
messages, the system further comprising a prioritization 
module coupled to the message generation module and 
establishing a priority of the plurality of messages, and 
wherein the communication layer transmits the plurality 
of messages in accordance with the priority established 
by the prioritization module. 

33. A system as recited in claim 24, wherein 

the communication layer retransmits the message if a 

.., re ?? on f\ e ;_ h ? s „ n ° t _ been . £. e J?,?*Y?3 ? ron l the. subscriber in_ a_ 
predetermined period of time. 

34. A system as recited in claim 24, wherein 
the communication layer receives an acknowledgement that 
the message was successfully transmitted oyer at least 
one of the at least two channels of communication. 

35. A system as recited in claim 24, further 
comprising and encryption module coupled to the message 
generation module, the encryption module encrypting the 
message prior to its transmission by the communication 
layer. 

36. A system as recited in claim 24, further 
comprising a message formatter coupled to the message 
generation module, the message formatter formatting the 
message for each of the at least. two channels of 
communication prior to transmission by the communication 
layer. 

37. A system as recited in claim 24, wherein 
the update information is time critical. 
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38. A system as recited in claim 24, further 
comprising an interface in the communication to at least 
one alternative channel of communication with which to 
communicate with the subscriber; and 

Wherein the communication layer transmits the 
message over the at least one alternative channel of 
communication if a response has not been received from 
the subscriber in a predetermined period of time. 

39. A system as recited in claim 24, further 
comprising an administration module coupled to the 
message generation module, the administration module 
assigning a time at which the message will become stale. 

40. A system as recited in claim 39, wherein 
the communication layer periodically retransmits the 
message until the message becomes stale or until a 
response is received from the subscriber. 

41. A system for communicating with 
subscribers comprising: 

an information identification module 
identifying update information related to the subscriber; 

a message generation module coupled to the 
information identification module and generating a 
message containing the update information; 

at least one communication channel; 

a communication channel interface coupled to 
the message generation module and coupled to the at least 
one communication channel, the communication channel 
interface transmitting the message to the subscriber on 
the at least one communication channel and receiving a 
response from the subscriber on the at least one 
communication channel; and 
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a response module coupled to the communication 
channel interface and correlating the received response 
to the transmitted message. 
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